On Fri, 04 May 2012 15:08:57 -0400, Chris Knadle wrote: > On Monday, April 30, 2012 10:53:46, Camaleón wrote: >> On Sun, 29 Apr 2012 20:16:58 +0200, Martin Steigerwald wrote: >> > Am Dienstag, 24. April 2012 schrieb Camaleón: > ... >> > 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. > > On XFS, fsck is literally a no-op -- it does *not* fsck the filesystem.
Well, at least there are "xfsprogs". > The steps to actually fsck a XFS filesystem: > - mount the XFS filesystem to replay the log > - unmount the XFS filesystem that was just mounted > - run xfs_check on the filesystem's device > - if necessary run xfs_repair on the filesystem's device You mean you don't even notice a file system inconsistency until it royally crashes or even something worse? Oh. > Note this means running 'xfs_check' is done when the filesystem is not > mounted. _Supposedly_ it can also be run if the filesystem is mounted > read- only, but in practice I find it's best (and easier) to run the XFS > commands from a LiveCD. The xfs_check and xfs_repair operations are > incredibly fast -- even for a 500GB filesystem it's usually only takes > about 10 or 15 seconds. Speed is generally what XFS is good at, *except* > when it comes to deletion of a large number of files -- that's where > it's slow. So... is that you don't find it suitable for a standard "/" partition? I mean, if it's better don't analyze an XFS partition when is mounted read-only, that can be really a no-no for many installations running 24/365. > Also in practice I find that any kernel crash or hard-power-off corrupts > XFS to at least some extent requiring an xfs_check and xfs_repair, so I > have to make sure to keep a LiveCD on hand to be able to do this. I've also heard about terrific stories of data lose after an unexpected power failure on volumes running on XFS but as I said before, I have no direct experience with this file system so I can't comment. > This gets even more interesting when running XFS on top of LUKS > encryption. I'm currently doing that, and I have had to do an xfs_repair > operation -- it involves running cryptsetup manually at the command line > within a LiveCD and then running xfs_repair on the newly created > unencrypted device. [And of course you have to know to look and make > sure the LiveCD contains those utilities.] Definitely an interesting > experience. File systems need a twist :-) > The main reason I've been running XFS is for speed -- even on top of > LUKS I'm finding XFS is able to do sustained 40MB/s transfers over 1Gb > ethernet, where ext4 on the same box is not able to sustain that. > However ext4 is more reliable and easier to deal with, because it's able > to run an fsck at boot time and without neeting a LiveCD to fix it. ;-) Not bad numbers. In the event I give XFS a whirl it will be over my "/data" partition, that's for sure... and fortunately all of my system have UPS units on behind O:-) 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/jo1hra$3du$1...@dough.gmane.org
