[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 2TB USB hard drive for backing up: XFS info



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


Reply to: