Hi all,
Firstly, Please CC me into replies as I'm not subscribed to this list.
I'm trying to confirm that Fedora 18 has enabled trim for XFS filesystems. I have added discard to the mount options in /etc/fstab - however I do not see it when looking at the output of 'mount':
UUID=b95a7b45-d197-45c0-a7d6-c13f930a38b3 / xfs defaults,discard 0 1
/dev/sda2 on / type xfs (rw,relatime,attr2,inode64,noquota)
fstrim shows that trim is at least enabled, but I am unable to confirm if it is done in realtime, or I am required to run fstrim manually.
# fstrim -v / /: 48919015424 bytes were trimmed
Can anyone share some insight into this?
On 2013-03-31, 01:38 GMT, Steven Haigh wrote:
Firstly, Please CC me into replies as I'm not subscribed to this list.
http://linuxmafia.com/~rick/faq/?page=netiquette#privatereply
On Sun, 2013-03-31 at 09:51 +0200, Matej Cepl wrote:
On 2013-03-31, 01:38 GMT, Steven Haigh wrote:
Firstly, Please CC me into replies as I'm not subscribed to this list.
http://linuxmafia.com/~rick/faq/?page=netiquette#privatereply
The gentleman did not ask for a private reply, he asked for a copy. Not the same thing at all. Being on the mailing list can mean getting the emails, and he clearly doesn't want to follow the entire list.
You could argue that we would be missing his contributions, but that may not be the case, he may be replying to posts already and following the list on line.
On Sun, Mar 31, 2013 at 9:51 AM, Matej Cepl mcepl@redhat.com wrote:
On 2013-03-31, 01:38 GMT, Steven Haigh wrote:
Firstly, Please CC me into replies as I'm not subscribed to this list.
http://linuxmafia.com/~rick/faq/?page=netiquette#privatereply
He just asked for being CCed not for a private reply.
On 2013-03-31, 15:55 GMT, drago01 wrote:
On Sun, Mar 31, 2013 at 9:51 AM, Matej Cepl mcepl@redhat.com wrote:
On 2013-03-31, 01:38 GMT, Steven Haigh wrote:
Firstly, Please CC me into replies as I'm not subscribed to this list.
http://linuxmafia.com/~rick/faq/?page=netiquette#privatereply
He just asked for being CCed not for a private reply.
Right, I have misunderstood his intent and I am sorry.
Matěj
Please, no flame. One thing on this mailing list that i like it is the near absence of flame. IMHO, one has to accept requests from those who do not follow the mailing, if appropriate and useful. I think this is the case. Just an opinion.
Best
On Sun, Mar 31, 2013 at 9:51 AM, Matej Cepl mcepl@redhat.com wrote:
On 2013-03-31, 01:38 GMT, Steven Haigh wrote:
Firstly, Please CC me into replies as I'm not subscribed to this list.
http://linuxmafia.com/~rick/faq/?page=netiquette#privatereply
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Sat, Mar 30, 2013 at 9:38 PM, Steven Haigh netwiz@crc.id.au wrote:
Hi all,
Firstly, Please CC me into replies as I'm not subscribed to this list.
I'm trying to confirm that Fedora 18 has enabled trim for XFS filesystems. I have added discard to the mount options in /etc/fstab - however I do not see it when looking at the output of 'mount':
UUID=b95a7b45-d197-45c0-a7d6-c13f930a38b3 / xfs defaults,discard 0 1
/dev/sda2 on / type xfs (rw,relatime,attr2,inode64,noquota)
fstrim shows that trim is at least enabled, but I am unable to confirm if it is done in realtime, or I am required to run fstrim manually.
# fstrim -v / /: 48919015424 bytes were trimmed
Can anyone share some insight into this?
IIRC you have to rebuild your initrd so it picks up the new fstab mount options for /, the other options is you should be able to do mount -o remount,discard /. Thanks,
Josef
On 04/02/2013 12:19 AM, Josef Bacik wrote:
On Sat, Mar 30, 2013 at 9:38 PM, Steven Haigh netwiz@crc.id.au wrote:
Hi all,
Firstly, Please CC me into replies as I'm not subscribed to this list.
I'm trying to confirm that Fedora 18 has enabled trim for XFS filesystems. I have added discard to the mount options in /etc/fstab - however I do not see it when looking at the output of 'mount':
UUID=b95a7b45-d197-45c0-a7d6-c13f930a38b3 / xfs defaults,discard 0 1
/dev/sda2 on / type xfs (rw,relatime,attr2,inode64,noquota)
fstrim shows that trim is at least enabled, but I am unable to confirm if it is done in realtime, or I am required to run fstrim manually.
# fstrim -v / /: 48919015424 bytes were trimmed
Can anyone share some insight into this?
IIRC you have to rebuild your initrd so it picks up the new fstab mount options for /, the other options is you should be able to do mount -o remount,discard /. Thanks,
Hi Josef,
This was the basis of my query - even after a remount with the discard option, 'discard' still wasn't present in the options - as seen by the mount line quoted above.
On 4/1/13 5:26 PM, Steven Haigh wrote:
On 04/02/2013 12:19 AM, Josef Bacik wrote:
On Sat, Mar 30, 2013 at 9:38 PM, Steven Haigh netwiz@crc.id.au wrote:
Hi all,
Firstly, Please CC me into replies as I'm not subscribed to this list.
I'm trying to confirm that Fedora 18 has enabled trim for XFS filesystems. I have added discard to the mount options in /etc/fstab - however I do not see it when looking at the output of 'mount':
...
Can anyone share some insight into this?
IIRC you have to rebuild your initrd so it picks up the new fstab mount options for /, the other options is you should be able to do mount -o remount,discard /. Thanks,
Hi Josef,
This was the basis of my query - even after a remount with the discard option, 'discard' still wasn't present in the options - as seen by the mount line quoted above.
Sorry I didn't see this earlier. Josef is right; discard is not a remountable option on xfs, unfortunately (only inode64 and barrier options are remountable today). So you could either put the option in the rootflags= kernel commandline parameter, or rebuild the initrd after adding it to fstab as Josef suggested so that it's initially mounted with the option.
I wonder if we should add something to the remount path to printk when a non-remountable option is encountered; I might look into that, otherwise it's a little surprising (although semi-obvious when the problem doesn't show up in /prcoc/mounts...).
Thanks, -Eric
On 03/04/13 01:08, Eric Sandeen wrote:
On 4/1/13 5:26 PM, Steven Haigh wrote:
On 04/02/2013 12:19 AM, Josef Bacik wrote:
On Sat, Mar 30, 2013 at 9:38 PM, Steven Haigh netwiz@crc.id.au wrote:
Hi all,
Firstly, Please CC me into replies as I'm not subscribed to this list.
I'm trying to confirm that Fedora 18 has enabled trim for XFS filesystems. I have added discard to the mount options in /etc/fstab - however I do not see it when looking at the output of 'mount':
...
Can anyone share some insight into this?
IIRC you have to rebuild your initrd so it picks up the new fstab mount options for /, the other options is you should be able to do mount -o remount,discard /. Thanks,
Hi Josef,
This was the basis of my query - even after a remount with the discard option, 'discard' still wasn't present in the options - as seen by the mount line quoted above.
Sorry I didn't see this earlier. Josef is right; discard is not a remountable option on xfs, unfortunately (only inode64 and barrier options are remountable today). So you could either put the option in the rootflags= kernel commandline parameter, or rebuild the initrd after adding it to fstab as Josef suggested so that it's initially mounted with the option.
Thanks for the reply Eric. I believe it would be helpful if this was documented. I was expecting it to work the same way as ext4 - being a simple remount would enable the discard option. Once that didn't work - and especially as I didn't get an error in either the syslog or returned from the command, I was starting to think it was a bug in the implementation of TRIM in XFS.
I wonder if we should add something to the remount path to printk when a non-remountable option is encountered; I might look into that, otherwise it's a little surprising (although semi-obvious when the problem doesn't show up in /prcoc/mounts...).
I think this is probably the best way to handle things. The first thing I did was to look at the return code from mount (which returned 0 - ie success), then dmesg, then /var/log/messages. As I found nothing, I had no hints on where to look.
The wiki page[1] for XFS does state that XFS supports TRIM - and it mentions the changes to /etc/fstab to enable it. It doesn't however mention that it needs to be on the initial mount - or that a remount will not enable it.
The best of both worlds would be to have it output to the dmesg - or even fail the mount command (if that is an option?) just like ext4 would if you supply a bogus option set.
1: http://xfs.org/index.php/FITRIM/discard
On 04/02/2013 10:26 AM, Steven Haigh wrote:
On 03/04/13 01:08, Eric Sandeen wrote:
On 4/1/13 5:26 PM, Steven Haigh wrote:
On 04/02/2013 12:19 AM, Josef Bacik wrote:
On Sat, Mar 30, 2013 at 9:38 PM, Steven Haigh netwiz@crc.id.au wrote:
Hi all,
Firstly, Please CC me into replies as I'm not subscribed to this list.
I'm trying to confirm that Fedora 18 has enabled trim for XFS filesystems. I have added discard to the mount options in /etc/fstab - however I do not see it when looking at the output of 'mount':
...
Can anyone share some insight into this?
IIRC you have to rebuild your initrd so it picks up the new fstab mount options for /, the other options is you should be able to do mount -o remount,discard /. Thanks,
Hi Josef,
This was the basis of my query - even after a remount with the discard option, 'discard' still wasn't present in the options - as seen by the mount line quoted above.
Sorry I didn't see this earlier. Josef is right; discard is not a remountable option on xfs, unfortunately (only inode64 and barrier options are remountable today). So you could either put the option in the rootflags= kernel commandline parameter, or rebuild the initrd after adding it to fstab as Josef suggested so that it's initially mounted with the option.
Thanks for the reply Eric. I believe it would be helpful if this was documented. I was expecting it to work the same way as ext4 - being a simple remount would enable the discard option. Once that didn't work - and especially as I didn't get an error in either the syslog or returned from the command, I was starting to think it was a bug in the implementation of TRIM in XFS.
I wonder if we should add something to the remount path to printk when a non-remountable option is encountered; I might look into that, otherwise it's a little surprising (although semi-obvious when the problem doesn't show up in /prcoc/mounts...).
I think this is probably the best way to handle things. The first thing I did was to look at the return code from mount (which returned 0 - ie success), then dmesg, then /var/log/messages. As I found nothing, I had no hints on where to look.
The wiki page[1] for XFS does state that XFS supports TRIM - and it mentions the changes to /etc/fstab to enable it. It doesn't however mention that it needs to be on the initial mount - or that a remount will not enable it.
The best of both worlds would be to have it output to the dmesg - or even fail the mount command (if that is an option?) just like ext4 would if you supply a bogus option set.
Is there any reason that discard cannot be enabled on remount like it is for other file systems? And disabled on remount for completeness?
Seems like something that we would definitely want to be consistent across file systems on,
Ric
On 4/2/13 9:30 AM, Ric Wheeler wrote:
On 04/02/2013 10:26 AM, Steven Haigh wrote:
On 03/04/13 01:08, Eric Sandeen wrote:
On 4/1/13 5:26 PM, Steven Haigh wrote:
On 04/02/2013 12:19 AM, Josef Bacik wrote:
On Sat, Mar 30, 2013 at 9:38 PM, Steven Haigh netwiz@crc.id.au wrote:
Hi all,
Firstly, Please CC me into replies as I'm not subscribed to this list.
I'm trying to confirm that Fedora 18 has enabled trim for XFS filesystems. I have added discard to the mount options in /etc/fstab - however I do not see it when looking at the output of 'mount':
...
Can anyone share some insight into this?
IIRC you have to rebuild your initrd so it picks up the new fstab mount options for /, the other options is you should be able to do mount -o remount,discard /. Thanks,
Hi Josef,
This was the basis of my query - even after a remount with the discard option, 'discard' still wasn't present in the options - as seen by the mount line quoted above.
Sorry I didn't see this earlier. Josef is right; discard is not a remountable option on xfs, unfortunately (only inode64 and barrier options are remountable today). So you could either put the option in the rootflags= kernel commandline parameter, or rebuild the initrd after adding it to fstab as Josef suggested so that it's initially mounted with the option.
Thanks for the reply Eric. I believe it would be helpful if this was documented. I was expecting it to work the same way as ext4 - being a simple remount would enable the discard option. Once that didn't work - and especially as I didn't get an error in either the syslog or returned from the command, I was starting to think it was a bug in the implementation of TRIM in XFS.
I wonder if we should add something to the remount path to printk when a non-remountable option is encountered; I might look into that, otherwise it's a little surprising (although semi-obvious when the problem doesn't show up in /prcoc/mounts...).
I think this is probably the best way to handle things. The first thing I did was to look at the return code from mount (which returned 0 - ie success), then dmesg, then /var/log/messages. As I found nothing, I had no hints on where to look.
The wiki page[1] for XFS does state that XFS supports TRIM - and it mentions the changes to /etc/fstab to enable it. It doesn't however mention that it needs to be on the initial mount - or that a remount will not enable it.
The best of both worlds would be to have it output to the dmesg - or even fail the mount command (if that is an option?) just like ext4 would if you supply a bogus option set.
Is there any reason that discard cannot be enabled on remount like it is for other file systems? And disabled on remount for completeness?
Discard should be one of the easier ones to change on remount; things like quota are tougher. I was talking w/ Dave about this just yesterday, and he pointed out that we might need to serialize access to some of the things that would get changed on a remount.
BTW Steven - we often recommend against runtime trim, and suggest fstrim instead, for performance reasons. Just something to maybe keep in mind and experiment with.
-Eric
Seems like something that we would definitely want to be consistent across file systems on,
Ric
On 03/04/13 01:46, Eric Sandeen wrote:
BTW Steven - we often recommend against runtime trim, and suggest fstrim instead, for performance reasons. Just something to maybe keep in mind and experiment with.
Thats ok - this isn't for a high-performance system - this is just me messing around on my EEEPC with a 64Gb SSD. Its better for me to have TRIM in runtime because anything (and I mean anything!) would beat the stock 5400rpm drive that was originally in it - that and it isn't on 24/7 to run fstrim in cron - which is probably the preferred method :)
I've used XFS on some large (by my standards, probably not by yours) filesystems over the years and really like it - seeing Fedora 18 supported XFS as root, I though I'd give it a try. There is no real technical reason other than 'because I can' :)
On 4/2/13 9:26 AM, Steven Haigh wrote:
On 03/04/13 01:08, Eric Sandeen wrote:
snip
I wonder if we should add something to the remount path to printk when a non-remountable option is encountered; I might look into that, otherwise it's a little surprising (although semi-obvious when the problem doesn't show up in /prcoc/mounts...).
I think this is probably the best way to handle things. The first thing I did was to look at the return code from mount (which returned 0 - ie success), then dmesg, then /var/log/messages. As I found nothing, I had no hints on where to look.
FWIW, there is some history here w/ returning 0/success for these options:
/* * Logically we would return an error here to prevent * users from believing they might have changed * mount options using remount which can't be changed. * * But unfortunately mount(8) adds all options from * mtab and fstab to the mount arguments in some cases * so we can't blindly reject options, but have to * check for each specified option if it actually * differs from the currently set option and only * reject it if that's the case. * * Until that is implemented we return success for * every remount request, and silently ignore all * options that we can't actually change. */ #if 0 xfs_info(mp, "mount option "%s" not supported for remount\n", p); return -EINVAL; #else break; #endif
Not great, but there it is.
-Eric
-
devzero2000 -
drago01 -
Eric Sandeen -
Howard Howell -
Josef Bacik -
Matej Cepl -
Ric Wheeler -
Steven Haigh