Re: The danger of dishonest disk drives (WAS:Re: Need to remove a ghost file, but can't because it doesn't exist)
On Thu, Nov 23, 2006 at 02:25:57PM -0500, Douglas Tutty wrote:
> On Wed, Nov 22, 2006 at 10:52:07AM -0500, hendrik@topoi.pooq.com wrote:
> > On Tue, Nov 21, 2006 at 10:38:45AM -0500, Douglas Tutty wrote:
> > >
> >
> > > So I use JFS for everything.
> > >
> > I looked a dmesg output, and in the midle it says:
> >
> > [ 31.547456] Probing IDE interface ide0...
> > [ 31.837706] hda: WDC WD2500JB-00GVC0, ATA DISK drive
> > [ 32.511260] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> > [ 32.511467] Probing IDE interface ide1...
> > [ 32.800442] hdc: WDC WD2500JB-00GVC0, ATA DISK drive
> > [ 33.247857] hdd: HL-DT-ST DVDRAM GSA-4167B, ATAPI CD/DVD-ROM drive
> > [ 33.307431] ide1 at 0x170-0x177,0x376 on irq 15
> > [ 33.319500] hda: max request size: 1024KiB
> > [ 33.330796] hda: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63, UDMA(100)
> > [ 33.332722] hda: cache flushes supported
> > [ 33.332762] hda: hda1 hda2 hda3
> > [ 33.351996] hdc: max request size: 1024KiB
> > [ 33.368251] hdc: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63, UDMA(33)
> > [ 33.370187] hdc: cache flushes supported
> > [ 33.370204] hdc: hdc1 hdc3
> > [ 33.381946] hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
> >
> > Do you have similar lines in your dmesg output?
> >
> > The key words here are "cache flushes supported", suggesting to me that
> > it is indeed possible for a file system to flush the cache, creating
> > safe points in the journalling. Does anyone know if my interpretation
> > is correct?
> >
> > The remaining questin is whether these cache flushes are indeed carried
> > out at the right moments.
> >
> > I've found the following references to suggest that some attempt is
> > being made to so this, but the exact status is unclear to me:
> >
> > http://oss.sgi.com/projects/xfs/faq.html
> > http://lwn.net/Articles/157209/
> >
> > The latter of the two is a commit message that commits changes to a
> > file called
> > blk-fixes/Documentation/block/barrier.txt
> > Now if I could find the rest of that file, things might be clearer.
>
> Hi Hendrik,
>
> The faq link you gave is for xfs which is defferent from jfs.
I'm aware of this. I dug up this information because I wanted to find
out whether the hardware would be up to the task if the filesystem is.
Because if the hardware says data are permanently recorded when they
haven't been, what can the file system do. Cache flushes potentially
create sync points where everything is properly committed.
The blk-fixes stuff seems to discuss what the kernel people are trying
to do about retining proper state on involuntary shutdown. If I
could only find the rest of this documentation. Of what system is this
the blk-fixes/Documentation/block/barrier.txt file? Where is the whole
thing, as opposed to the patches, documented?
>
> I have no lines on either of my boxes mentioning cache flushes. Then
> again, I found WD drives unreliable for some reason and perhaps this is
> why. Now, I only use Seagate.
My suspicion is that supporting cache flushes means that it does have a
mechanism to create proper symc points by flushing the cache.
Not supporting them means either that
it can't provide sync points and fhe file system is helpless
or that
it doesn't need to because it doesn't cache or lie about writing, and
the file system can do its business properly.
>
> The best source of jfs information is from ibm. The easiest way to
> locate this is with google:
>
> jfs site:ibm.com
>
> Although since IBM likes to move stuff around, google often can't find
> things. So use the search function on IBM's website at www.ibm.com
> Also, today, I'm not getting a response from ibm.com/developerworks,
> which is where most of the linux jfs documentation is.
Will look. Thanks.
>
> Note that IBM does say that jfs focus more on being able to restore
> filesystem integrity than on data integrity. For higher integrity they
> suggest the sync mount option.
reiser4 is *supposed* to care about data integrity as well. But it's
still not in a stable release according to its developer (last time I
looked) and he seems to be in jail at the moment.
ext3 is supposed to care about data integrity *if* you specify the right
mount options.
>
> What I haven't seen covered is how the fs/lvm/raid1 interact re the fs
> committing the journal to disk. There's probably a 2.6 kernel internals
> document that discusses this but I haven't seen it yet.
>
> I wonder if there is a filesystem designed from the outset for data
> integrity after power-failure.
That's what journals are supposed to do -- if the disk drives don't lie
to them. Whether the journals are properly implemented is another
matter.
-- hendrik
Reply to: