[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [suse-security] Filesystem choice in secure server installati on
On Thursday 22 January 2004 16:09, Avtar Gill wrote:
> I've read that ext3 (since it's based on ext2) has been in existence
> longer than the other filesystems so it has been more thoroughly stress
> tested. Then again there are reports about filesystem corruption with
> pretty much any filesystem so everyone's mileage will vary regardless.
ext2 has been one of the oldest file systems in the Linux kernel. It is also
very small (~5.000 lines of kernel code when I studied it, ~7.000 lines now,
Suse Linux kernel sources taken as a reference). reiserfs is much more
complex than ext2, though - about 25.000 lines (compare: xfs is ~83.000
lines, ext3 is ~10.000 lines). The difference in size is mostly because of
the difference in feature sets - ext2/ext3 is rather primitive compared to
reiserfs or xfs, and with ext3 catching up in features it will also catch up
ext3 is an extension to ext2, and this extension is much younger. In fact,
ext3 is pretty much a work in progress - the journalling part now being
complete, and other extensions being written right now.
reiserfs has been in the kernel longer than ext3 has been, and been in use
with Suse Linux kernels even longer. Also, in Suse Linux, reiserfs has been
the default filesystem for quite some time now, so one can reasonably expect
it to be stress tested in a way comparable to ext2.
On recovery and fscking: Both reiserfs and XFS are filesystems with dynamic
metadata, while in ext2/ext3, the metadata is preallocated and metadata
positions are fixed.
That is: in ext2/ext3, you can more or less tell if a block is a metadata
block by simply looking at the block number, while in dynamic metadata
filesystems you need to look at the actual block contents. That makes work
slightly harder for file system checkers.
That being said, I can report from personal experience that the reiserfs file
system checker is quite good. I had a severe system crash on my system with
some hundred megabytes of buffer cache in flight during a major disk space
cleanup action. That crash was not related to reiserfs, but a badly
configured agpgart, but it corrupted my / and /home partitions beyond simple
log rollback nonetheless and I had to reiserfsck both partitions. One
partition, /home, even needed a complete rebuild check.
reiserfsck did this, and in a very successful way. It read all data blocks of
the partition and identified metadata by inspecting magic bytes in each
block. From the metadata blocks it identified, it rebuilt the complete
filesystem structure and recovered all data blocks. The filesystem is now
online again, and with very minimal data loss.
In fact, reiserfsck was a bit more successful than I expected. I had several
vmware vmdk files on /home which also contained reiserfs filesystems inside.
reiserfsck identified metadata signatures in these blocks and tried to link
the contents of these files into the main filesystem. In doing to it
discovered that this would lead to a crosslinked structure (blocks being
metadata- and data-blocks at the same time, and blocks referenced
twite),sucessfully duplicated these blocks, and relinked the duplicated
structures under lost+found.
I ended up with some 1.2 GB contents from inside the vmdk files properly
duplicated, reconstructed and relinked under lost+found, which I simply
deleted, and all was well.
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here