| |||||||||||||
|
| |||||||||||||
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration)Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration)Posted Apr 26, 2006 1:47 UTC (Wed) by dlang (✭ supporter ✭, #313)In reply to: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration) by sbergman27 Parent article: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration)
keep in mind that these benifits you are listing only count if you are useing a hard drive that allows you to disable the write cache on it (i.e. no IDE drives qualify). if the drive can tell you that the write is completed while it's in the drives memory it's still vundrable to being lost.
since there is a huge performance penalty for doing this it's seldom done even on the drives that support it.
David Lang
P.S. and no, the drives don't use their platter energy to drive the electronics long enough to write their data. as an excercise consider how many seeks could be required to write all the data in a 16M buffer, and how long that could take. then add in the problems of writing to a platter that's slowing down as you write and you start to realize why nobody does that anymore.
(Log in to post comments)
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration) Posted Apr 26, 2006 2:49 UTC (Wed) by sbergman27 (subscriber, #10767) [Link] There is a difference between the benefits "not counting" and the guarantees not being absolute.
But you are correct. Hardware write caching does figure in.
You *can* turn write caching off on most IDE drives but, as you say, there is a considerable performance penalty due to the insane limitation on write request size imposed by the ATA standard. So far as i know, SCSI drives are not so hampered.
P.S. Did I say something about the drive using its platter energy for something?
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration) Posted Apr 26, 2006 7:28 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link] no, you didn't say anything aobut platter energy, but it's a common misconception that people have about drives and the cache on them
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration) Posted Apr 26, 2006 15:14 UTC (Wed) by sbergman27 (subscriber, #10767) [Link] I saw refernces to that misconception twice yesterday. Oddly, the last time I encountered it (that I remember) was in 1979 when my first computer science instructor made reference to the "fact" that the drive did that. I believed it at the time, and then later decided it was urban legend.
I notice in your previous post you indicate that they don't do that "anymore". Did they really used to do that?
Also of note, and sorry, I don't have a ready link, I was once struck by a thread on lkml in which someone was crash testing different filesystems under Linux. He had a filesystem with lots of writes going on and knew what all the md5sums should be or something like that and would then pull the plug at random times and observe what happened. His question to the list was for someone to please point out what he was "doing wrong". You see, all the other filesystems in the test corrupted files with more or less the same frequency. All except for ext3, that is. It seemed never (or very rarely) to ever corrupt files and he felt that there must be a problem with his methodology. It was explained that ext3 defaults to data=ordered mode and that such behavior was really expected.
My summary of the thread is probably not completely accurate because it's been a while since I read it, but I was struck by the fact that someone observed the difference even though they were not expecting it.
If I can dig up a link, I'll post it.
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration) Posted Apr 26, 2006 16:15 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link] >I notice in your previous post you indicate that they don't do that "anymore". Did they really used to do that?
I don't know for sure, but every urban legend needs to get started somewhere right? :-)
thinking about it from a practical standpoint, at one point drives had very small buffers (ram was too expensive, and too large to put much on a drive) along with a lot of rotating mass, so it would have been possible to flush that buffer immediatly on power-loss (and the tolorances of the data on disk were loose enough to accept the slight distortion that would result).
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration) Posted Apr 26, 2006 6:46 UTC (Wed) by joib (guest, #8541) [Link] keep in mind that these benifits you are listing only count if you are useing a hard drive that allows you to disable the write cache on it (i.e. no IDE drives qualify).As was already mentioned, most IDE drives allow you to disable write-back cache. However, many manufacturers consider this operation a warranty-voiding one, since disabling write-back caching causes much more physical writes which significantly reduces the life of the drive. if the drive can tell you that the write is completed while it's in the drives memory it's still vundrable to being lost. since there is a huge performance penalty for doing this it's seldom done even on the drives that support it. Fortunately, you can have your cake and eat it too. The trick is to implement IO barriers using the CACHE FLUSH and/or FUA commands. That way you can have the performance and MTBF benefits of write-back caching while still having a safe fsync() (safe as in doesn't return before data is on the platters). Also note that the IO barrier rewrite referenced above was included only from 2.6.16+; I don't know how previous kernels did it.
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration) Posted Apr 26, 2006 7:29 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link] I hadn't caught the fact that the IO barriers had made it into the kernel, I knew they were being worked on. prior to that going in the only option the kernel had was to stop all IO to the drive while issueing a full flush to it.
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration) Posted May 6, 2006 13:56 UTC (Sat) by anton (subscriber, #25547) [Link] >hard drive that allows you to disable the write cache on it (i.e. no>IDE drives qualify).
hdparm -W0 works on any IDE drive I have tried it on (and we run all
>since there is a huge performance penalty for doing this
Well, I recently tried it:
Disk: SAMSUNG SV1204H, ATA DISK drive
So the penalty was a factor of 2 in this case.
>as an excercise consider how many seeks could be required to write all
The drive could have a 16MB spare area for just this case, and dump
|
|
||||||||||||