On 4/29/2011 1:51 PM, prad wrote:
Ron Johnson<ron.l.johnson@cox.net> 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 too. ;)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.
-- Stan