[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 
in complexity.

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