On 9/28/10 11:47 , Francis Galiegue wrote:
As to file system hardening, what do you mean apart from checksums?
Fundamental filesystem design?
I specifically mean the intended ability to survive a power failure.
Historically, unix file systems lived in the disk cache such that a
power failure would result in a polluted file system. This would
require an fsck pass to clear out the errors and "recover" the file
system although data lost was still data lost.
A while back, (some time in the 90's), most unix file systems were
"hardened" such that a power failure would generally _not_ result in a
file system pollution. Ext2 is not hardened. Ext3 has an optional
journal which provides file system hardening.
Ext2 is faster than ext3 but also suffers from smaller file system size
limits. Btrfs, in "-m single -d single" mode is hardened and competes
favorably against ext2 for speed. All other linux file systems are
either not hardened, slower, or both. (Although nilfs2 is also hardened
and somewhere between ext2 and ext3 speeds.)
#15 presupposes it's own answer. While I've had no filesystems fail, every
machine I use with btrfs file systems has failed numerous times -
pathological behavior, kernel crashes, etc. In the absence of a btrfsck I
can't be sure that the file system has actually failed although rebuilding
the file system seems to alleviate the symptoms temporarily.
I don't really see your point here. Can you elaborate? And yes, I _do_
mean filesystem failures, not machine failure. I made that explicit.
It's simple. I can't tell if I've had file system pollution because we
don't have a functional btrfsck. I only know that I have file systems
which have reached a state where the kernel was unable to use them
constructively. I can't tell whether this state was due to a data error
in the file system or a coding error in the file system driver which
couldn't cope with a valid state of the file system.
#16 presupposes a failure mode. Again, my issues have more to do with
stability than with clear cases of file system pollution
Point taken, but again, this is on purpose, I talk here about hosed
filesystems indeed.
Then I think you need to ask the same question again with respect to
system failures due to btrfs which aren't necessarily file system failures.
Imagine this for a moment - pretend that any time btrfs were in your
kernel your kernel were only capable of network speeds of 1Mbps. Data
was correct both in your btrfs file systems and in your network
interfaces - but you were horribly restricted in your network
interfaces. This would not represent a polluted btrfs file system and
yet it would clearly represent a "broken" system by most people's
definitions. It's these cases I'm looking to see represented in the
questionnaire because these are the types of failures I've been seeing.
And in the absence of a reliable btrfsck, we can't really determine the
existence of file system pollution anyway - we can only guess that we
might have polluted file systems.
--rich
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
