On Friday, May 04, 2012 17:31:23, Camaleón wrote: > 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: ... > > 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. Yes that's corret -- XFS does /not/ warn you at boot time (nor mount time) if the state of the filesystem is inconsistent. YOU have to know to check that (or find out "the hard way"), and if you use XFS for "/" you somehow need to know to do it from a LiveCD. :-/ [This is rarely explained.] > > 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? Hmm. Having given that a thought -- yeah I think that would be a good idea and I might be happier using ext4 for "/" and keep using XFS for /home. On my next reinstall of my laptop (whatever year that will be :-P) I might try that and see how I like it. > 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. Yes. And in addition nounting a "/" XFS partition read-only to run xfs_repair on is fairly tricky. Even when booting up into single-user mode it's still necessary to shut down several processes, which last I recall also includes the sshd daemon. :-/ I'm currently using XFS for "/" on a remote server I have no physical access to, and I'm finding this is a problem because I don't have a good way of running xfs_check and xfs_repair on it while the system is running. The hosting company supports remote KVM and bootup to a LiveCD of your choice, and I think this is basically what I'd have to resort to using if I wanted to run xfs_repair on "/" on that box. > > 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. I've experienced some data loss due to unclean shutdowns, so I can verify that that's possible. I have not yet had any "massive" data loss, thankfully. ... > > 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. BTW these numbers are with 1Gb ethernet /without/ using jumbo frames -- this is because the unmanaged switch I'm using doesn't support them. > 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:-) All of the systems I'm using XFS on have UPSes on them too -- yet I find systems I run go down hard once in a blue moon, so IMHO a UPS won't completely save you from needing to run xfs_check and xfs_repair occasionally. -- Chris -- Chris Knadle Chris.Knadle@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74
Attachment:
signature.asc
Description: This is a digitally signed message part.