The danger of dishonest disk drives (WAS:Re: Need to remove a ghost file, but can't because it doesn't exist)
On Tue, Nov 21, 2006 at 10:38:45AM -0500, Douglas Tutty wrote:
>
> All I know is what I've experienced and what I have taken on faith:
>
> Reiserfs looses files on panic powerdowns (power failure) even if the
> filesystem structure survives. Reiserfsck doesn't fix this. This, for
> me, has been small files (unfortunaly, typically those in /etc) even
> though they weren't being written at the time of the power failure.
>
> IBM says they designed JFS to allow a server to get back to work quickly
> after a power failure, which includes fixing problems so that it __can__
> work. I have enough experience with IBM to trust that when they design
> something to put their name on it (and use it in AIX) that it will do
> what they say it will do.
>
> I tried to stress-test JFS by __moving__ directories from one drive to
> another and one partition to another and cutting the power in the
> middle. The move would only be partially complete but no files were
> lost; they either existed on one drive or the other, nothing got lost in
> limbo.
>
> Until I got my new Athlon system, I have always used old/slow hardware.
> Looking at the benchmark comparisions, reiserfs may be faster with small
> files because it embeds them in the directory structure but to do that
> it needs a lot more CPU overhead. So on my hardware, JFS has been
> faster than reiserfs.
>
> So I use JFS for everything.
>
> Doug.
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.
-- hendrik
Reply to: