8:38 p.m.
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?
--
Steven Haigh
Email: netwiz(a)crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299
2:51 a.m.
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
10:53 a.m.
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.
10:55 a.m.
On Sun, Mar 31, 2013 at 9:51 AM, Matej Cepl <mcepl(a)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.
2:43 p.m.
On 2013-03-31, 15:55 GMT, drago01 wrote:
On Sun, Mar 31, 2013 at 9:51 AM, Matej Cepl <mcepl(a)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
2:18 p.m.
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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
8:19 a.m.
On Sat, Mar 30, 2013 at 9:38 PM, Steven Haigh <netwiz(a)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
5:26 p.m.
On 04/02/2013 12:19 AM, Josef Bacik wrote:
On Sat, Mar 30, 2013 at 9:38 PM, Steven Haigh
<netwiz(a)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.
--
Steven Haigh
Email: netwiz(a)crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299
9:08 a.m.
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(a)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
9:26 a.m.
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(a)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
--
Steven Haigh
Email: netwiz(a)crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299
9:30 a.m.
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(a)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
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
9:46 a.m.
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(a)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
>
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
10:09 a.m.
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' :)
--
Steven Haigh
Email: netwiz(a)crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299
1:26 p.m.
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
4039
days inactive
4041
days old
13 comments
8 participants
participants (8)
-
devzero2000 -
drago01 -
Eric Sandeen -
Howard Howell -
Josef Bacik -
Matej Cepl -
Ric Wheeler -
Steven Haigh