Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
TRIM support with XFS
1,443 views
Skip to first unread message
John Andreasson
Jun 29, 2013, 2:50:01 PM6/29/13
to
Hello.
I have a question about XFS and TRIM on SSD. I'm unable to determine if I can use it in Debian 7.1. I have searched the documentation and found positive information on ext4, but not on XFS.
Just to test I installed Wheezy on a ThinkPad equipped with an SSD and picked XFS as the root file system. After installing it I added discard to the mount options in /etc/fstab and rebooted the machine. Discard diesn't however appear in the mount options for the file system if I run the mount command. So it looks like it's not picked up when the file system is mounted.
I then tried running a manual TRIM with fstrim -v /. It did not print any error messages and appears to work.
So my question is: Does TRIM work with XFS in Wheezy and what should I do to use it?
John
Hans-J. Ullrich
Jun 29, 2013, 3:10:01 PM6/29/13
to
> So my question is: Does TRIM work with XFS in Wheezy and what should I do
> to use it?
>
> John
as far as I know, the partitions will be correct created by debian. Trimmings
is not a problem of the filesystem, but of partitioning. So, you can either
partitition with debian (whhezy or higher), or you can also use a live-file cd
like "gparted-live". It is the kernel, who is responsible for that. 3.2 and
higher will always work.
Have fun!
Best regards
Hans
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201306292106.25...@loop.de
John Andreasson
Jun 29, 2013, 3:30:01 PM6/29/13
to
On Saturday, June 29, 2013, Hans-J. Ullrich wrote:
as far as I know, the partitions will be correct created by debian. Trimmings
is not a problem of the filesystem, but of partitioning. So, you can either
partitition with debian (whhezy or higher), or you can also use a live-file cd
like "gparted-live". It is the kernel, who is responsible for that. 3.2 and
higher will always work.
I'm not sure I follow. I've always thought that it is the file system that is responsible for sending the trim command to the SSD. Are you saying that it depends on the partitioning? I'm not using any intermediate layer like LVM or RAID, which I guess would otherwise have to pass the commands down the chain.
John
Christoph Anton Mitterer
Jun 29, 2013, 3:30:01 PM6/29/13
to
No... what you mean is alignment... and that is not only dependant on the partitions..but every block layer from the file system to the physical medium.
TRIM depends on support from all the layers as well... from the fs to the physical medium, including LVM, RAID or dmcrypt.
Chris.
"Hans-J. Ullrich" <hans.u...@loop.de> schrieb:
Archive: http://lists.debian.org/860991a8-19ef-42f0...@email.android.com
TRIM depends on support from all the layers as well... from the fs to the physical medium, including LVM, RAID or dmcrypt.
Chris.
"Hans-J. Ullrich" <hans.u...@loop.de> schrieb:
Stan Hoeppner
Jun 29, 2013, 4:20:02 PM6/29/13
to
On 6/29/2013 1:46 PM, John Andreasson wrote:
> Hello.
>
> I have a question about XFS and TRIM on SSD. I'm unable to determine if I
> can use it in Debian 7.1. I have searched the documentation and found
> positive information on ext4, but not on XFS.
>
> Just to test I installed Wheezy on a ThinkPad equipped with an SSD and
> picked XFS as the root file system. After installing it I added discard to
> the mount options in /etc/fstab and rebooted the machine. Discard diesn't
> however appear in the mount options for the file system if I run the mount
> command. So it looks like it's not picked up when the file system is
> mounted.
Mount is miserly on the info it gives you. Post the output of
> Hello.
>
> I have a question about XFS and TRIM on SSD. I'm unable to determine if I
> can use it in Debian 7.1. I have searched the documentation and found
> positive information on ext4, but not on XFS.
>
> Just to test I installed Wheezy on a ThinkPad equipped with an SSD and
> picked XFS as the root file system. After installing it I added discard to
> the mount options in /etc/fstab and rebooted the machine. Discard diesn't
> however appear in the mount options for the file system if I run the mount
> command. So it looks like it's not picked up when the file system is
> mounted.
~$ cat /proc/mounts
Then read this:
http://xfs.org/index.php/FITRIM/discard
and note [4]
For a single user desktop productivity system, realtime discard w/XFS
probably won't show a noticeable negative impact, but this obviously
depends on your workloads. If you frequently delete very large files
(10s of GB), or very large numbers of files, then you may notice a slowdown.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
green
Jun 29, 2013, 4:50:01 PM6/29/13
to
John Andreasson wrote at 2013-06-29 13:46 -0500:
> So my question is: Does TRIM work with XFS in Wheezy and what should I do
> to use it?
See <http://xfs.org/index.php/FITRIM/discard>. Add the 'discard'
> So my question is: Does TRIM work with XFS in Wheezy and what should I do
> to use it?
mount option in /etc/fstab. I suppose, to trim all old eraseable
blocks, you should also remount with 'discard' (or reboot), and use
fstrim once.
John Andreasson
Jun 29, 2013, 5:10:01 PM6/29/13
to
On Sat, Jun 29, 2013 at 10:17 PM, Stan Hoeppner <st...@hardwarefreak.com> wrote:
Mount is miserly on the info it gives you. Post the output of
~$ cat /proc/mounts
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=10240k,nr_inodes=2043449,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=1635204k,mode=755 0 0
/dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / xfs rw,noatime,attr2,delaylog,noquota 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=6601880k 0 0
/dev/sda1 /boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=utf8,shortname=mixed,errors=remount-ro 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
Doesn't look promising. The mount options in /etc/fstab is default,discard,native.
/sys/block/sda/queue/discard_max_bytes says 2147450880. So it looks like at least the block device is recognized to support discard operations.
For a single user desktop productivity system, realtime discard w/XFS
probably won't show a noticeable negative impact, but this obviously
depends on your workloads. If you frequently delete very large files
(10s of GB), or very large numbers of files, then you may notice a slowdown.
Very infrequent. :-)
John
Stan Hoeppner
Jun 29, 2013, 7:20:01 PM6/29/13
to
Please keep replies on list.
On 6/29/2013 3:57 PM, John Andreasson wrote:
> /dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / xfs
> rw,noatime,attr2,delaylog,noquota 0 0
Post the XFS mount entry(s) in dmesg and any errors.
> Doesn't look promising. The mount options in /etc/fstab is
> default,discard,noatime.
Paste the exact line from /etc/fstab.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/51CF6B0B...@hardwarefreak.com
On 6/29/2013 3:57 PM, John Andreasson wrote:
> /dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / xfs
> rw,noatime,attr2,delaylog,noquota 0 0
> Doesn't look promising. The mount options in /etc/fstab is
Paste the exact line from /etc/fstab.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stan Hoeppner
Jun 29, 2013, 7:50:02 PM6/29/13
to
On 6/29/2013 6:17 PM, Stan Hoeppner wrote:
> Please keep replies on list.
>
> On 6/29/2013 3:57 PM, John Andreasson wrote:
>
>> /dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / xfs
>> rw,noatime,attr2,delaylog,noquota 0 0
>
> Post the XFS mount entry(s) in dmesg and any errors.
>
>> Doesn't look promising. The mount options in /etc/fstab is
>> default,discard,noatime.
>
> Paste the exact line from /etc/fstab.
I should have remembered this sooner. You're using initrd I assume
> Please keep replies on list.
>
> On 6/29/2013 3:57 PM, John Andreasson wrote:
>
>> /dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / xfs
>> rw,noatime,attr2,delaylog,noquota 0 0
>
> Post the XFS mount entry(s) in dmesg and any errors.
>
>> Doesn't look promising. The mount options in /etc/fstab is
>> default,discard,noatime.
>
> Paste the exact line from /etc/fstab.
since this is a stock install. The problem here is that the rootfs is
being mounted via initrd. If you didn't rebuild it after adding discard
to /etc/fstab, this explains your problem.
Rebuilding initrd should fix it.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
John Andreasson
Jun 30, 2013, 12:50:01 AM6/30/13
to
On Sun, Jun 30, 2013 at 1:47 AM, Stan Hoeppner <st...@hardwarefreak.com> wrote:
> Post the XFS mount entry(s) in dmesg and any errors.
[ 2.119489] SGI XFS with ACLs, security attributes, realtime, large
> Post the XFS mount entry(s) in dmesg and any errors.
block/inode numbers, no debug enabled
[ 2.119716] SGI XFS Quota Management subsystem
[ 2.120753] XFS (sda2): Mounting Filesystem
[ 2.150708] XFS (sda2): Ending clean mount
> Paste the exact line from /etc/fstab.
defaults 0 1
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / xfs
defaults,discard,noatime 0 1
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none swap sw
0 0
> I should have remembered this sooner. You're using initrd I assume
> since this is a stock install. The problem here is that the rootfs is
> being mounted via initrd. If you didn't rebuild it after adding discard
> to /etc/fstab, this explains your problem.
>
> Rebuilding initrd should fix it.
install. I've rebuilt the inird and rebooted the machine; but no
change in /proc/mounts.
root# update-initramfs -d -k all
update-initramfs: Deleting /boot/initrd.img-3.2.0-4-amd64
root# update-initramfs -c -k 3.2.0-4-amd64
update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64
John
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stan Hoeppner
Jun 30, 2013, 6:10:01 PM6/30/13
to
On 6/29/2013 11:45 PM, John Andreasson wrote:
> On Sun, Jun 30, 2013 at 1:47 AM, Stan Hoeppner <st...@hardwarefreak.com> wrote:
>> Post the XFS mount entry(s) in dmesg and any errors.
>
> [ 2.119489] SGI XFS with ACLs, security attributes, realtime, large
> block/inode numbers, no debug enabled
> [ 2.119716] SGI XFS Quota Management subsystem
> [ 2.120753] XFS (sda2): Mounting Filesystem
> [ 2.150708] XFS (sda2): Ending clean mount
>
>> Paste the exact line from /etc/fstab.
>
> UUID=xxxx-xxxx /boot/efi vfat
> defaults 0 1
> UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / xfs
> defaults,discard,noatime 0 1
> UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none swap sw
> 0 0
>
>> I should have remembered this sooner. You're using initrd I assume
>> since this is a stock install. The problem here is that the rootfs is
>> being mounted via initrd. If you didn't rebuild it after adding discard
>> to /etc/fstab, this explains your problem.
>>
>> Rebuilding initrd should fix it.
>
> Apart from the change in default file system it's pretty much a stock
> install. I've rebuilt the inird and rebooted the machine; but no
> change in /proc/mounts.
Hmm...
> On Sun, Jun 30, 2013 at 1:47 AM, Stan Hoeppner <st...@hardwarefreak.com> wrote:
>> Post the XFS mount entry(s) in dmesg and any errors.
>
> [ 2.119489] SGI XFS with ACLs, security attributes, realtime, large
> block/inode numbers, no debug enabled
> [ 2.119716] SGI XFS Quota Management subsystem
> [ 2.120753] XFS (sda2): Mounting Filesystem
> [ 2.150708] XFS (sda2): Ending clean mount
>
>> Paste the exact line from /etc/fstab.
>
> UUID=xxxx-xxxx /boot/efi vfat
> defaults 0 1
> UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / xfs
> defaults,discard,noatime 0 1
> UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none swap sw
> 0 0
>
>> I should have remembered this sooner. You're using initrd I assume
>> since this is a stock install. The problem here is that the rootfs is
>> being mounted via initrd. If you didn't rebuild it after adding discard
>> to /etc/fstab, this explains your problem.
>>
>> Rebuilding initrd should fix it.
>
> Apart from the change in default file system it's pretty much a stock
> install. I've rebuilt the inird and rebooted the machine; but no
> change in /proc/mounts.
Last thing to try is rootflags. To your kernel line in menu.lst add
root=/dev/sdXX rootflags=discard ro
If that doesn't do it maybe there's a bug here.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
John Andreasson
Jul 5, 2013, 3:10:01 AM7/5/13
to
On Mon, Jul 1, 2013 at 12:05 AM, Stan Hoeppner <st...@hardwarefreak.com> wrote:
> Hmm...
>
> Last thing to try is rootflags. To your kernel line in menu.lst add
>
> root=/dev/sdXX rootflags=discard ro
Thanks. I tried that as well but it still doesn't work.
> Hmm...
>
> Last thing to try is rootflags. To your kernel line in menu.lst add
>
> root=/dev/sdXX rootflags=discard ro
Just to be sure I created a file with random data, read the sectors
with hdparm and then removed the file and did a flush. If discard was
active the sector should be zeroed out. It was however still there
after a sync, and also after waiting an hour just in case.
> If that doesn't do it maybe there's a bug here.
I took a look at the xfs source code in the kernel tree. It looks like
the discard code is simply never called except for when there's an
ioctl call. I guess that's what fstrim triggers. But from what I could
see there's no realtime support in kernel right now. I guess I should
go with ext4 for now.
John
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stan Hoeppner
Jul 5, 2013, 2:30:01 PM7/5/13
to
On 7/5/2013 2:07 AM, John Andreasson wrote:
> On Mon, Jul 1, 2013 at 12:05 AM, Stan Hoeppner <st...@hardwarefreak.com> wrote:
>> Hmm...
>>
>> Last thing to try is rootflags. To your kernel line in menu.lst add
>>
>> root=/dev/sdXX rootflags=discard ro
>
> Thanks. I tried that as well but it still doesn't work.
>
> Just to be sure I created a file with random data, read the sectors
> with hdparm and then removed the file and did a flush. If discard was
> active the sector should be zeroed out. It was however still there
> after a sync, and also after waiting an hour just in case.
>
>> If that doesn't do it maybe there's a bug here.
>
> It sounds like that.
>
> I took a look at the xfs source code in the kernel tree. It looks like
> the discard code is simply never called except for when there's an
> ioctl call. I guess that's what fstrim triggers. But from what I could
> see there's no realtime support in kernel right now. I guess I should
> go with ext4 for now.
Ask on the XFS mailing list. I'm pretty sure some of the XFS devs use
> On Mon, Jul 1, 2013 at 12:05 AM, Stan Hoeppner <st...@hardwarefreak.com> wrote:
>> Hmm...
>>
>> Last thing to try is rootflags. To your kernel line in menu.lst add
>>
>> root=/dev/sdXX rootflags=discard ro
>
> Thanks. I tried that as well but it still doesn't work.
>
> Just to be sure I created a file with random data, read the sectors
> with hdparm and then removed the file and did a flush. If discard was
> active the sector should be zeroed out. It was however still there
> after a sync, and also after waiting an hour just in case.
>
>> If that doesn't do it maybe there's a bug here.
>
> It sounds like that.
>
> I took a look at the xfs source code in the kernel tree. It looks like
> the discard code is simply never called except for when there's an
> ioctl call. I guess that's what fstrim triggers. But from what I could
> see there's no realtime support in kernel right now. I guess I should
> go with ext4 for now.
XFS as rootfs w/Debian on SSD (Dave Chinner IIRC). According to
Christoph discard should work with any kernel above 3.0--Wheezy is
3.2--as long as the other requirements are met. And your system seems
to meet the others.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages