Re: file systems
- To: firstname.lastname@example.org
- Subject: Re: file systems
- From: Stan Hoeppner <email@example.com>
- Date: Sat, 30 Apr 2011 23:47:08 -0500
- Message-id: <4DBCE5CC.firstname.lastname@example.org>
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org> <4DAE0FF0.email@example.com> <4DB513E5.firstname.lastname@example.org> <4DB5CC72.email@example.com> <4DB5EDAB.firstname.lastname@example.org> <4DB60919.email@example.com> <4DB60C9E.firstname.lastname@example.org> <4DB630D1.email@example.com> <4DB646ED.firstname.lastname@example.org> <4DB67726.email@example.com> <4DB6D6C0.firstname.lastname@example.org> <4DB73CB2.email@example.com> <4DB749DE.firstname.lastname@example.org> <4DBAFF13.email@example.com> <4DBB0279.firstname.lastname@example.org> <email@example.com>
On 4/29/2011 1:51 PM, prad wrote:
Ron Johnson<firstname.lastname@example.org> writes:
On 04/29/2011 01:10 PM, Stan Hoeppner wrote:
On 4/26/2011 5:40 PM, Ron Johnson wrote:
But not being able to fsck the fs that I just created is unacceptable.
Again, 'xfs_repair -n' is functionally equivalent to 'xfs_check'. They
are two methods (paths) that (should) arrive at the same result. Either
will let you know if the filesystem has errors.
Have you run 'xfs_repair -n' yet to see if it trips over your per
process memory limit? If it doesn't, you have your fsck and can eat it
I already converted to ext4.
and i have converted to xfs!
i am very impressed so far and will try to document my experiences with
it as a sort of 'noob guide' ... if only to help myself out. :D
thx again stan! i'm looking forward to learning about the filesystem,
something i never bothered with in the past.
It shines brightest with heavy multitasking/multiuser IO workloads
manipulating large files when atop Linux MD or hardware RAID. Its
performance is merely average in most cases on a single disk system.
It's advantage over all other Linux FSes on single disk systems is
online defragmentation. For example, if you have a local mailbox file
in mbox format (any Mozilla MUA) it will always get heavily fragmented.
Cron'ing xfs_fsr twice a week will eliminate the performance hit to
your MUA that accompanies such fragmentation.
To get maximum metadata performance you need kernel 2.6.36 or later with
the mount option 'delaylog' in fstab. In 2.6.39 and later delaylog is
the default. This will dramatically decrease execution time of things
like unpacking a kernel tar file or running 'rm -rf' on a huge directory
tree of a few thousand files. It will also increase maildir performance
substantially on busy IMAP servers.