noatime,nodiratime?
Need a little education here. I have a general understanding of what the inode access timestamps "are" but I have no idea what, if any, applications make use of these access times. I see posts all over Google land saying to use "noatime,nodiratime,logbufs=8" for XFS mount options to increase performance.
Is there any potential downside to disabling atime? Do daemons such as Dovecot or Samba need these access times updated? Do any applications need this?
Thanks.
Signature · 6 lines
Stan _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 5 lines · Stan Hoeppner
Need a little education here. I have a general understanding of what the inode access timestamps "are" but I have no idea what, if any, applications make use of these access times. I see posts all over Google land saying to use "noatime,nodiratime,logbufs=8" for XFS mount options to increase performance.
BTW, about the mount options for XFS, is there a way to check for the default values (things like logbsize, logbufs, something else)?
I used to have noatime,logbufs=8,logbsize=256k on my fileserver, not sure if these are still necessary.
Thanks,
Signature · 6 lines
Nicolas _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Nicolas KOWALSKI put forth on 5/19/2010 12:33 PM:
Quoted 7 lines
Quoted 5 lines · Stan Hoeppner
Need a little education here. I have a general understanding of what the inode access timestamps "are" but I have no idea what, if any, applications make use of these access times. I see posts all over Google land saying to use "noatime,nodiratime,logbufs=8" for XFS mount options to increase performance.
Quoted 5 lines
BTW, about the mount options for XFS, is there a way to check for the default values (things like logbsize, logbufs, something else)?
I used to have noatime,logbufs=8,logbsize=256k on my fileserver, not sure if these are still necessary.
Yes, the defaults for each parameter are in your mount man page. logbsize=256K is higher than the default, which is 32K for any system with over 32MB RAM. logbufs=8 will be the default if your blocksize is 64K. If your blocksize is 4K you'll get logbufs=2 by default. This is all in the XFS section of man mount.
Signature · 6 lines
Stan _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 5 lines · Stan Hoeppner
Need a little education here. I have a general understanding of what the inode access timestamps "are" but I have no idea what, if any, applications make use of these access times. I see posts all over Google land saying to use "noatime,nodiratime,logbufs=8" for XFS mount options to increase performance.
Which doesn't make much sense. First 8 log buffers has been the default for XFS for a long time. Second nodiratime has always been useless as it is a strict subset of of noatime. Now noatime isn't the default yet, but instead relatime is, which still updates the atime in memory, but only writes it back when the inode has other changes, or on umount. It should give you equivalent performance to noatime, but better functionality.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 5 lines · Stan Hoeppner
Yes, the defaults for each parameter are in your mount man page. logbsize=256K is higher than the default, which is 32K for any system with over 32MB RAM. logbufs=8 will be the default if your blocksize is 64K. If your blocksize is 4K you'll get logbufs=2 by default. This is all in the XFS section of man mount.
But it's not actually true anymore for a long time. XFS is always using 8 32k log buffers these days. I'll prepare an update for the mount man page to correct this.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Christoph Hellwig
Quoted 5 lines · Stan Hoeppner
Yes, the defaults for each parameter are in your mount man page. logbsize=256K is higher than the default, which is 32K for any system with over 32MB RAM. logbufs=8 will be the default if your blocksize is 64K. If your blocksize is 4K you'll get logbufs=2 by default. This is all in the XFS section of man mount.
But it's not actually true anymore for a long time. XFS is always using 8 32k log buffers these days. I'll prepare an update for the mount man page to correct this.
Ok, Thanks for the reminder and update.
Signature · 6 lines
Nicolas _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Christoph Hellwig put forth on 5/19/2010 1:23 PM:
Quoted 7 lines · Stan Hoeppner
Quoted 5 lines
Need a little education here. I have a general understanding of what the inode access timestamps "are" but I have no idea what, if any, applications make use of these access times. I see posts all over Google land saying to use "noatime,nodiratime,logbufs=8" for XFS mount options to increase performance.
Quoted 7 lines
Which doesn't make much sense. First 8 log buffers has been the default for XFS for a long time. Second nodiratime has always been useless as it is a strict subset of of noatime. Now noatime isn't the default yet, but instead relatime is, which still updates the atime in memory, but only writes it back when the inode has other changes, or on umount. It should give you equivalent performance to noatime, but better functionality.
Wow. That'll teach me to trust that man pages are accurate. :) Maybe you could add this explanation about relatime vs noatime to the man page as well.
Any chance xfs_info could be updated to output the information we're discussing, including spitting out the XFS specific mount options that are currently active at the time of running xfs_info? There seems to be much confusion in the community due to lack of accurate information being available. Google for "XFS performance" and you'll see "noatime,nodiratime,logbufs=8" mentioned consistently from early 2000's to the present as a performance enhancer.
If what you say is true, on my 2.6.32.9 system, I actually decreased logbufs from 8 to 4 half an hour ago, instead of increasing it from 2 to 4, as man lead me to believe I was doing. Do any of the xfs tools output the XFS specific active mount options allowing an op to confirm changes? As someone else stated it would be nice to be able to see these parameter values. As is, AFAICT, there's no way to confirm these parameter values.
Signature · 6 lines
Stan _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 3 lines · Stan Hoeppner
Any chance
xfs_infocould be updated to output the information we're discussing, including spitting out the XFS specific mount options that are currently active at the time of runningxfs_info?
xfs_info actually calls xfs_growfs -n, and it's only reporting on-disk geometry. I kind of doubt that'll change. If you want to see mount options, /proc/mounts is the place ... but then we don't show the defaults ;) I wonder if we should change that and be explicit about every option in /proc/mounts *shrug*
Quoted 5 lines
There seems to be much
confusion in the community due to lack of accurate information being available. Google for "XFS performance" and you'll see "noatime,nodiratime,logbufs=8" mentioned consistently from early 2000's to the present as a performance enhancer.
It's so hard to keep google up to date ;)
Quoted 6 lines
If what you say is true, on my 2.6.32.9 system, I actually decreased logbufs from 8 to 4 half an hour ago, instead of increasing it from 2 to 4, as man lead me to believe I was doing. Do any of the xfs tools output the XFS specific active mount options allowing an op to confirm changes? As someone else stated it would be nice to be able to see these parameter values. As is, AFAICT, there's no way to confirm these parameter values.
/proc/mounts shows all mount options which were set differently from defaults.
-Eric
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Eric Sandeen put forth on 5/19/2010 2:50 PM:
Quoted 5 lines
xfs_infoactually callsxfs_growfs-n, and it's only reporting on-disk geometry. I kind of doubt that'll change. If you want to see mount options,/proc/mountsis the place ... but then we don't show the defaults ;) I wonder if we should change that and be explicit about every option in/proc/mounts*shrug*
IMHO the option values should be listed, whether they are the defaults or user defined. XFS may be breaking convention by doing so, as it appears EXT2 (and probably 3/4, and other filesystems) behave the same as XFS currently does--no display of default settings, except rw.
Quoted 1 line
It's so hard to keep google up to date ;)
Add the information to the FAQ and it'll show up in Google indexes in short order, assuming you allow robots to crawl xfs.org, which IIRC, you do.
Quoted 2 lines
/proc/mountsshows all mount options which were set differently from defaults.
Yes. It would be nice to see the settings regardless of default or user defined. In the absence of, or in addition to this, could we get a consistent (default) for each setting in XFS man mount? For example, barrier is listed but we're not told if it's the default. nobarrier isn't even in the man page, but it's on the wiki FAQ. The wiki FAQ tells us that barrier is the default. I'm referring to the man page that comes with Debian 5.0. The current man page may be updated to reflect some of these things, though I've not read it yet.
Sorry if I seem nit-picky. I've spent many hours trying to hunt down some of this information and it's been a frustrating process. XFS rocks. Currently, from here, the docs don't rock yet. :(
Signature · 6 lines
Stan _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 2 lines · On Donnerstag, 20. Mai 2010 Stan Hoeppner wrote:
Yes. It would be nice to see the settings regardless of default or
user defined.
I second that. Because you could use barrier in the fstab options, but it's not supported and so nobarrier is used. It would be good to check that by simply "cat /proc/mounts".
Signature · 10 lines
mit freundlichen Grüssen, Michael Monnerie, Ing. BSc it-management Internet Services http://proteger.at [gesprochen: Prot-e-schee] Tel: 0660 / 415 65 31 // Wir haben im Moment zwei Häuser zu verkaufen: // http://zmi.at/langegg/ // http://zmi.at/haus2009/
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 30 lines · Stan Hoeppner
Eric Sandeen put forth on 5/19/2010 2:50 PM:
Quoted 5 lines
xfs_infoactually callsxfs_growfs-n, and it's only reporting on-disk geometry. I kind of doubt that'll change. If you want to see mount options,/proc/mountsis the place ... but then we don't show the defaults ;) I wonder if we should change that and be explicit about every option in/proc/mounts*shrug*IMHO the option values should be listed, whether they are the defaults or user defined. XFS may be breaking convention by doing so, as it appears EXT2 (and probably 3/4, and other filesystems) behave the same as XFS currently does--no display of default settings, except rw.
Quoted 1 line
It's so hard to keep google up to date ;)
Add the information to the FAQ and it'll show up in Google indexes in short order, assuming you allow robots to crawl xfs.org, which IIRC, you do.
Quoted 2 lines
/proc/mountsshows all mount options which were set differently from defaults.Yes. It would be nice to see the settings regardless of default or user defined. In the absence of, or in addition to this, could we get a consistent (default) for each setting in XFS man mount? For example, barrier is listed but we're not told if it's the default. nobarrier isn't even in the man page, but it's on the wiki FAQ. The wiki FAQ tells us that barrier is the default. I'm referring to the man page that comes with Debian 5.0. The current man page may be updated to reflect some of these things, though I've not read it yet.
Quoted 3 lines
Sorry if I seem nit-picky. I've spent many hours trying to hunt down some of this information and it's been a frustrating process. XFS rocks. Currently, from here, the docs don't rock yet. :(
Patches to fix up the docs will be gratefully accepted. :) Patches to change the output of /proc/mounts might take a little more discussion....
Note that the man pages for mount are in the util-linux package, not anything XFS...
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs