On Sun, 29 Apr 2012 20:16:58 +0200, Martin Steigerwald wrote: > Am Dienstag, 24. April 2012 schrieb Camaleón:
(...) >> As an aside note, I've been using ReiserFS in all of my linux boxes (in >> both, servers and workstations) for the "/" partition and I never had >> to face the long waits at booting till the fsck ends. I know that >> ReiserFS (v3) is not actively developed (just security patches) and >> performs better for small files but I'm considering in moving ext3 to >> XFS or another mature file system (JFS) because the annoying and >> absurdly long time fsck takes. > > Reiserfs has some more drawbacks: > > - long mount times on large volumes > > - doesn´t distinguish between different filesystems on fsck like > - loopback file with reiserfs on reiserfs > - vm image file with reiserfs on reiserfs > > Especially the latter is a no-go for me, cause an fsck would mix up the > several reiserfs filesstems. I haven't had experienced any of that issues in any of my systems so I still find ReaiserFS the most suitable filesystem for me. The only big drawback I see for ReiserFS v3 is that it does not receive more enhancements nor features just patches, which can leave your installation in a very delicated state if something goes wrong. OTOH, I don't know about the current status of ReiserFS v4, I have not heard any news since many years :-? > XFS might also have long file check times. I still have not tried this so I can't really tell but what I've heard on XFS is not comparable to ext3, I mean, in regards with the time it takes to perform a filesystem check. > fsck times depend more on the number of inodes than on the size of the > filesystem. They also depend on the version of the check tool. > > XFS develovers tuned xfs_repair heavily regarding speed and memory > usage. And I seem to recall some optimizations for Ext4 as well, like > unitialized block groups (bguninit or something lile that in tunefs -l). > > My Ext4 fsck times on large volumes are quite good. A few minutes > usually. Even on the backup drive which holds at least 1 million inodes > in one logical volume. My experience with ext3 and fsck times also varies depending of the volume file size: my 500 GiB hard disk can delay up to 5 min. but the server's 1.2 TiB volume do take longer... >> > Its very convenient to have a large sack to toss the stuff, but it >> > has its own set of drawbacks :) >> >> Yes, and I'm against partitioning too much but considering the big >> sizes of the actual hard disks it has become a must, also to minimize a >> filesystem corruption in a partition that can affect the whole data. > > I use LVM quite a lot, but I am a bit annoyed by having to vgchange -ay > after inserting and vgchange -an before removal. I like to see a > removable flag for LVs that lessens the locking restrictions that are > important in certain enterprise setups, so that I can have an LVM be > scanned automatically and do not need to run vgchange. I wish hard disk partitioning becomes more handly and flexible and it gets implemented on the filesystem "natively" without having to deal with external tools, such as LVM. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jnm91q$kbo$3...@dough.gmane.org