linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
* [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
@ 2020-03-14 18:09 John
  2020-03-16  1:24 ` Chao Yu
  0 siblings, 1 reply; 16+ messages in thread
From: John @ 2020-03-14 18:09 UTC (permalink / raw)
  To: linux-f2fs-devel

Running `fstrim -a -v` is not detecting my f2fs partition that I
created just a few days ago but it does detect an older f2fs partition
and trims it as expected.  Both partitions are on the same SSD.  The
older partition is FSVER=1.12 whereas the newer one is FSVER=1.13
(reported by `lsblk -f`).

Invoking it manually on the newer one gives this:
# fstrim -v /mnt/media
fstrim: /mnt/media: the discard operation is not supported

And invoking it manually on the older one gives this:
# fstrim -v /incoming
/mnt/incoming:  1.7 GiB (1762152448 bytes) trimmed on /dev/sda2

Thanks.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
  2020-03-14 18:09 [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions John
@ 2020-03-16  1:24 ` Chao Yu
  2020-03-16  9:52   ` John
  0 siblings, 1 reply; 16+ messages in thread
From: Chao Yu @ 2020-03-16  1:24 UTC (permalink / raw)
  To: John, linux-f2fs-devel

Hello,

On 2020/3/15 2:09, John wrote:
> Running `fstrim -a -v` is not detecting my f2fs partition that I
> created just a few days ago but it does detect an older f2fs partition
> and trims it as expected.  Both partitions are on the same SSD.  The
> older partition is FSVER=1.12 whereas the newer one is FSVER=1.13
> (reported by `lsblk -f`).

What's your mount option and mkfs option on those two partitions, and what's
your kernel version?

I checked the code, only place where we give 'not supported' is as below
by checking whether underlying device supports discard.

f2fs_ioc_fitrim()

	if (!f2fs_hw_support_discard(F2FS_SB(sb)))
		return -EOPNOTSUPP;

So this should not happen that two partitions locates in one device have
inconsistent discard support status.

Thanks,

> 
> Invoking it manually on the newer one gives this:
> # fstrim -v /mnt/media
> fstrim: /mnt/media: the discard operation is not supported
> 
> And invoking it manually on the older one gives this:
> # fstrim -v /incoming
> /mnt/incoming:  1.7 GiB (1762152448 bytes) trimmed on /dev/sda2
> 
> Thanks.
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> .
> 


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
  2020-03-16  1:24 ` Chao Yu
@ 2020-03-16  9:52   ` John
  2020-03-17  1:44     ` Chao Yu
  0 siblings, 1 reply; 16+ messages in thread
From: John @ 2020-03-16  9:52 UTC (permalink / raw)
  To: linux-f2fs-devel

On Sun, Mar 15, 2020 at 9:24 PM Chao Yu <yuchao0@huawei.com> wrote:
>
> What's your mount option and mkfs option on those two partitions, and what's
> your kernel version?

I am mounting the partitions with systemd like so (/etc/fstab entry):
  LABEL=incoming         /incoming     f2fs  noauto,x-systemd.automount  0 0

But I can reproduce this if I totally remove the entries within
/etc/fstab, reboot, and mount manually like this:
  mount LABEL=incoming /incoming

Inspecting my shell history, I created them both with this command:
  mkfs.f2fs -l incoming /dev/sdb2

I am running 5.5.9 on Arch Linux, but I believe I experienced this
under previous 5.5.x series as well.

If you create a F2FS partition using the latest stable release of
f2fs-tools (1.13.0) are you able to reproduce the inability to trim?

Thank you for the consideration!

> I checked the code, only place where we give 'not supported' is as below
> by checking whether underlying device supports discard.
>
> f2fs_ioc_fitrim()
>
>         if (!f2fs_hw_support_discard(F2FS_SB(sb)))
>                 return -EOPNOTSUPP;
>
> So this should not happen that two partitions locates in one device have
> inconsistent discard support status.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
  2020-03-16  9:52   ` John
@ 2020-03-17  1:44     ` Chao Yu
  2020-03-18 20:25       ` John
  0 siblings, 1 reply; 16+ messages in thread
From: Chao Yu @ 2020-03-17  1:44 UTC (permalink / raw)
  To: John, linux-f2fs-devel

On 2020/3/16 17:52, John wrote:
> On Sun, Mar 15, 2020 at 9:24 PM Chao Yu <yuchao0@huawei.com> wrote:
>>
>> What's your mount option and mkfs option on those two partitions, and what's
>> your kernel version?
> 
> I am mounting the partitions with systemd like so (/etc/fstab entry):
>   LABEL=incoming         /incoming     f2fs  noauto,x-systemd.automount  0 0
> 
> But I can reproduce this if I totally remove the entries within
> /etc/fstab, reboot, and mount manually like this:
>   mount LABEL=incoming /incoming

However, the directory where you trigger trim is "/mnt/media"?

Quoted:
"Invoking it manually on the newer one gives this:
# fstrim -v /mnt/media
fstrim: /mnt/media: the discard operation is not supported"

Could you give more details about that? What device is behind /mnt/media?

> 
> Inspecting my shell history, I created them both with this command:
>   mkfs.f2fs -l incoming /dev/sdb2
> 
> I am running 5.5.9 on Arch Linux, but I believe I experienced this
> under previous 5.5.x series as well.
> 
> If you create a F2FS partition using the latest stable release of
> f2fs-tools (1.13.0) are you able to reproduce the inability to trim?

I can't, and also there is such option in mkfs to disable trim functionality
during format.

Thanks,

> 
> Thank you for the consideration!
> 
>> I checked the code, only place where we give 'not supported' is as below
>> by checking whether underlying device supports discard.
>>
>> f2fs_ioc_fitrim()
>>
>>         if (!f2fs_hw_support_discard(F2FS_SB(sb)))
>>                 return -EOPNOTSUPP;
>>
>> So this should not happen that two partitions locates in one device have
>> inconsistent discard support status.
> .
> 


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
  2020-03-17  1:44     ` Chao Yu
@ 2020-03-18 20:25       ` John
  2020-03-23  4:11         ` Jaegeuk Kim
  0 siblings, 1 reply; 16+ messages in thread
From: John @ 2020-03-18 20:25 UTC (permalink / raw)
  To: Chao Yu; +Cc: linux-f2fs-devel

On Mon, Mar 16, 2020 at 9:44 PM Chao Yu <yuchao0@huawei.com> wrote:
>
> On 2020/3/16 17:52, John wrote:
> > On Sun, Mar 15, 2020 at 9:24 PM Chao Yu <yuchao0@huawei.com> wrote:
> >>
> >> What's your mount option and mkfs option on those two partitions, and what's
> >> your kernel version?
> >
> > I am mounting the partitions with systemd like so (/etc/fstab entry):
> >   LABEL=incoming         /incoming     f2fs  noauto,x-systemd.automount  0 0
> >
> > But I can reproduce this if I totally remove the entries within
> > /etc/fstab, reboot, and mount manually like this:
> >   mount LABEL=incoming /incoming
>
> However, the directory where you trigger trim is "/mnt/media"?
>
> Quoted:
> "Invoking it manually on the newer one gives this:
> # fstrim -v /mnt/media
> fstrim: /mnt/media: the discard operation is not supported"
>
> Could you give more details about that? What device is behind /mnt/media?

The SSD has two partitions on it formatted to F2FS.
LABEL=incoming was created with f2fs-tools v1.12.0
LABEL=media was created with f2fs-tools v1.13.0

The physical device is a Samsung 860 EVO 2TB SSD.

> > Inspecting my shell history, I created them both with this command:
> >   mkfs.f2fs -l incoming /dev/sdb2
> >
> > I am running 5.5.9 on Arch Linux, but I believe I experienced this
> > under previous 5.5.x series as well.
> >
> > If you create a F2FS partition using the latest stable release of
> > f2fs-tools (1.13.0) are you able to reproduce the inability to trim?
>
> I can't, and also there is such option in mkfs to disable trim functionality
> during format.
>

I might be misunderstanding.  When you said "I can't" does that mean
when you created a partition with f2fstools v1.13.0, mounted it, and
then ran the fstrim on it, fstrim completed successfully?  Which
version of fstrim do you have installed?  I am using util-linux
2.35.1.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
  2020-03-18 20:25       ` John
@ 2020-03-23  4:11         ` Jaegeuk Kim
  2020-03-23 10:27           ` John
  0 siblings, 1 reply; 16+ messages in thread
From: Jaegeuk Kim @ 2020-03-23  4:11 UTC (permalink / raw)
  To: John; +Cc: linux-f2fs-devel

On 03/18, John wrote:
> On Mon, Mar 16, 2020 at 9:44 PM Chao Yu <yuchao0@huawei.com> wrote:
> >
> > On 2020/3/16 17:52, John wrote:
> > > On Sun, Mar 15, 2020 at 9:24 PM Chao Yu <yuchao0@huawei.com> wrote:
> > >>
> > >> What's your mount option and mkfs option on those two partitions, and what's
> > >> your kernel version?
> > >
> > > I am mounting the partitions with systemd like so (/etc/fstab entry):
> > >   LABEL=incoming         /incoming     f2fs  noauto,x-systemd.automount  0 0
> > >
> > > But I can reproduce this if I totally remove the entries within
> > > /etc/fstab, reboot, and mount manually like this:
> > >   mount LABEL=incoming /incoming
> >
> > However, the directory where you trigger trim is "/mnt/media"?
> >
> > Quoted:
> > "Invoking it manually on the newer one gives this:
> > # fstrim -v /mnt/media
> > fstrim: /mnt/media: the discard operation is not supported"

Hmm, could you share cat /proc/mounts?

> >
> > Could you give more details about that? What device is behind /mnt/media?
> 
> The SSD has two partitions on it formatted to F2FS.
> LABEL=incoming was created with f2fs-tools v1.12.0
> LABEL=media was created with f2fs-tools v1.13.0
> 
> The physical device is a Samsung 860 EVO 2TB SSD.
> 
> > > Inspecting my shell history, I created them both with this command:
> > >   mkfs.f2fs -l incoming /dev/sdb2
> > >
> > > I am running 5.5.9 on Arch Linux, but I believe I experienced this
> > > under previous 5.5.x series as well.
> > >
> > > If you create a F2FS partition using the latest stable release of
> > > f2fs-tools (1.13.0) are you able to reproduce the inability to trim?
> >
> > I can't, and also there is such option in mkfs to disable trim functionality
> > during format.
> >
> 
> I might be misunderstanding.  When you said "I can't" does that mean
> when you created a partition with f2fstools v1.13.0, mounted it, and
> then ran the fstrim on it, fstrim completed successfully?  Which
> version of fstrim do you have installed?  I am using util-linux
> 2.35.1.
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
  2020-03-23  4:11         ` Jaegeuk Kim
@ 2020-03-23 10:27           ` John
  2020-03-23 15:02             ` Jaegeuk Kim
  0 siblings, 1 reply; 16+ messages in thread
From: John @ 2020-03-23 10:27 UTC (permalink / raw)
  To: Jaegeuk Kim; +Cc: linux-f2fs-devel

On Mon, Mar 23, 2020 at 12:11 AM Jaegeuk Kim <jaegeuk@kernel.org> wrote:
>
> On 03/18, John wrote:
> > On Mon, Mar 16, 2020 at 9:44 PM Chao Yu <yuchao0@huawei.com> wrote:
> > >
> > > On 2020/3/16 17:52, John wrote:
> > > > On Sun, Mar 15, 2020 at 9:24 PM Chao Yu <yuchao0@huawei.com> wrote:
> > > >>
> > > >> What's your mount option and mkfs option on those two partitions, and what's
> > > >> your kernel version?
> > > >
> > > > I am mounting the partitions with systemd like so (/etc/fstab entry):
> > > >   LABEL=incoming         /incoming     f2fs  noauto,x-systemd.automount  0 0
> > > >
> > > > But I can reproduce this if I totally remove the entries within
> > > > /etc/fstab, reboot, and mount manually like this:
> > > >   mount LABEL=incoming /incoming
> > >
> > > However, the directory where you trigger trim is "/mnt/media"?
> > >
> > > Quoted:
> > > "Invoking it manually on the newer one gives this:
> > > # fstrim -v /mnt/media
> > > fstrim: /mnt/media: the discard operation is not supported"
>
> Hmm, could you share cat /proc/mounts?

Since I posted, I have completely reformatted the Samsung 860 EVO 2TB.
Now, it is just a single LUKS partition with f2fs.  I am getting the
same "fstrim: /mnt/media: the discard operation is not supported"
error when I try using fstrim -v /mnt/media with it.

Here is cat /proc/mounts, thank you for the consideration:
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sys /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
dev /dev devtmpfs rw,nosuid,relatime,size=3903292k,nr_inodes=975823,mode=755 0 0
run /run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0
/dev/sda2 / ext4 rw,relatime 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup2 /sys/fs/cgroup/unified cgroup2
rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0
cgroup /sys/fs/cgroup/systemd cgroup
rw,nosuid,nodev,noexec,relatime,xattr,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
none /sys/fs/bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/perf_event cgroup
rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup
rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/rdma cgroup rw,nosuid,nodev,noexec,relatime,rdma 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup
rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs
rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12920
0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime,pagesize=2M 0 0
mqueue /dev/mqueue mqueue rw,nosuid,nodev,noexec,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,nosuid,nodev,noexec,relatime 0 0
tracefs /sys/kernel/tracing tracefs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev 0 0
configfs /sys/kernel/config configfs rw,nosuid,nodev,noexec,relatime 0 0
systemd-1 /mnt/media autofs
rw,relatime,fd=49,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=14523
0 0
tmpfs /scratch tmpfs rw,lazytime,nodev,relatime,size=6291456k 0 0
nfsd /proc/fs/nfsd nfsd rw,relatime 0 0
/dev/mapper/media-crypt /mnt/media f2fs
rw,lazytime,relatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix
0 0
/dev/mapper/media-crypt /srv/nfs/share f2fs
ro,lazytime,relatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix
0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
tmpfs /run/user/1000 tmpfs
rw,nosuid,nodev,relatime,size=782676k,mode=700,uid=1000,gid=100 0 0


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
  2020-03-23 10:27           ` John
@ 2020-03-23 15:02             ` Jaegeuk Kim
  2020-03-23 20:12               ` John
  0 siblings, 1 reply; 16+ messages in thread
From: Jaegeuk Kim @ 2020-03-23 15:02 UTC (permalink / raw)
  To: John; +Cc: linux-f2fs-devel

On 03/23, John wrote:
> On Mon, Mar 23, 2020 at 12:11 AM Jaegeuk Kim <jaegeuk@kernel.org> wrote:
> >
> > On 03/18, John wrote:
> > > On Mon, Mar 16, 2020 at 9:44 PM Chao Yu <yuchao0@huawei.com> wrote:
> > > >
> > > > On 2020/3/16 17:52, John wrote:
> > > > > On Sun, Mar 15, 2020 at 9:24 PM Chao Yu <yuchao0@huawei.com> wrote:
> > > > >>
> > > > >> What's your mount option and mkfs option on those two partitions, and what's
> > > > >> your kernel version?
> > > > >
> > > > > I am mounting the partitions with systemd like so (/etc/fstab entry):
> > > > >   LABEL=incoming         /incoming     f2fs  noauto,x-systemd.automount  0 0
> > > > >
> > > > > But I can reproduce this if I totally remove the entries within
> > > > > /etc/fstab, reboot, and mount manually like this:
> > > > >   mount LABEL=incoming /incoming
> > > >
> > > > However, the directory where you trigger trim is "/mnt/media"?
> > > >
> > > > Quoted:
> > > > "Invoking it manually on the newer one gives this:
> > > > # fstrim -v /mnt/media
> > > > fstrim: /mnt/media: the discard operation is not supported"
> >
> > Hmm, could you share cat /proc/mounts?
> 
> Since I posted, I have completely reformatted the Samsung 860 EVO 2TB.
> Now, it is just a single LUKS partition with f2fs.  I am getting the
> same "fstrim: /mnt/media: the discard operation is not supported"
> error when I try using fstrim -v /mnt/media with it.
> 
> Here is cat /proc/mounts, thank you for the consideration:
> proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
> sys /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
> dev /dev devtmpfs rw,nosuid,relatime,size=3903292k,nr_inodes=975823,mode=755 0 0
> run /run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
> efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0
> /dev/sda2 / ext4 rw,relatime 0 0
> securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
> tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
> devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
> tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
> cgroup2 /sys/fs/cgroup/unified cgroup2
> rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0
> cgroup /sys/fs/cgroup/systemd cgroup
> rw,nosuid,nodev,noexec,relatime,xattr,name=systemd 0 0
> pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
> none /sys/fs/bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700 0 0
> cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
> cgroup /sys/fs/cgroup/perf_event cgroup
> rw,nosuid,nodev,noexec,relatime,perf_event 0 0
> cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
> cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
> cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
> cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
> cgroup /sys/fs/cgroup/cpu,cpuacct cgroup
> rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
> cgroup /sys/fs/cgroup/rdma cgroup rw,nosuid,nodev,noexec,relatime,rdma 0 0
> cgroup /sys/fs/cgroup/net_cls,net_prio cgroup
> rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
> cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
> cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
> systemd-1 /proc/sys/fs/binfmt_misc autofs
> rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12920
> 0 0
> hugetlbfs /dev/hugepages hugetlbfs rw,relatime,pagesize=2M 0 0
> mqueue /dev/mqueue mqueue rw,nosuid,nodev,noexec,relatime 0 0
> debugfs /sys/kernel/debug debugfs rw,nosuid,nodev,noexec,relatime 0 0
> tracefs /sys/kernel/tracing tracefs rw,nosuid,nodev,noexec,relatime 0 0
> tmpfs /tmp tmpfs rw,nosuid,nodev 0 0
> configfs /sys/kernel/config configfs rw,nosuid,nodev,noexec,relatime 0 0
> systemd-1 /mnt/media autofs
> rw,relatime,fd=49,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=14523
> 0 0
> tmpfs /scratch tmpfs rw,lazytime,nodev,relatime,size=6291456k 0 0
> nfsd /proc/fs/nfsd nfsd rw,relatime 0 0
> /dev/mapper/media-crypt /mnt/media f2fs
> rw,lazytime,relatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix

- media-crypt means dm-crypt? Any chance to try raw sda?

Could you try this?
- mount -o remount,nodiscard
 : The reason is, as f2fs uses async discard feature with -o discard, it doesn't
   give 0 bytes on fstrim sometimes.

> 0 0
> /dev/mapper/media-crypt /srv/nfs/share f2fs
> ro,lazytime,relatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix
> 0 0
> sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
> tmpfs /run/user/1000 tmpfs
> rw,nosuid,nodev,relatime,size=782676k,mode=700,uid=1000,gid=100 0 0


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
  2020-03-23 15:02             ` Jaegeuk Kim
@ 2020-03-23 20:12               ` John
  2020-03-24  2:32                 ` Chao Yu
  0 siblings, 1 reply; 16+ messages in thread
From: John @ 2020-03-23 20:12 UTC (permalink / raw)
  To: Jaegeuk Kim; +Cc: linux-f2fs-devel

On Mon, Mar 23, 2020 at 11:02 AM Jaegeuk Kim <jaegeuk@kernel.org> wrote:
> > /dev/mapper/media-crypt /mnt/media f2fs
> > rw,lazytime,relatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix
>
> - media-crypt means dm-crypt? Any chance to try raw sda?

Yes, it is dm-crypt.

> Could you try this?
> - mount -o remount,nodiscard
>  : The reason is, as f2fs uses async discard feature with -o discard, it doesn't
>    give 0 bytes on fstrim sometimes.

I can confirm it is mounted now with the nodiscard option, but fstrim
still claims discard is not supported.

% mount | grep crypt
/dev/mapper/media-crypt on /mnt/media type f2fs
(rw,relatime,lazytime,background_gc=on,nodiscard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix,x-systemd.automount)

# fstrim -v /mnt/media
fstrim: /mnt/media: the discard operation is not supported


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
  2020-03-23 20:12               ` John
@ 2020-03-24  2:32                 ` Chao Yu
       [not found]                   ` <CAO_nJAYWQWrWaQVfUmVpJGFtOeKKE76im-AkLUDTJm8DN4VAgA@mail.gmail.com>
  0 siblings, 1 reply; 16+ messages in thread
From: Chao Yu @ 2020-03-24  2:32 UTC (permalink / raw)
  To: John, Jaegeuk Kim; +Cc: linux-f2fs-devel

On 2020/3/24 4:12, John wrote:
> On Mon, Mar 23, 2020 at 11:02 AM Jaegeuk Kim <jaegeuk@kernel.org> wrote:
>>> /dev/mapper/media-crypt /mnt/media f2fs
>>> rw,lazytime,relatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix
>>
>> - media-crypt means dm-crypt? Any chance to try raw sda?
> 
> Yes, it is dm-crypt.
> 
>> Could you try this?
>> - mount -o remount,nodiscard
>>  : The reason is, as f2fs uses async discard feature with -o discard, it doesn't
>>    give 0 bytes on fstrim sometimes.
> 
> I can confirm it is mounted now with the nodiscard option, but fstrim
> still claims discard is not supported.

Can you try below command and show us the result to see whether device supports discard:

strace blkdiscard -o 0 -l 4096 /dev/mapper/media-crypt

It may discard first 4k block which is first superblock of f2fs, for safety, it will
be better to backup all your data before executing the command.

Thanks,

> 
> % mount | grep crypt
> /dev/mapper/media-crypt on /mnt/media type f2fs
> (rw,relatime,lazytime,background_gc=on,nodiscard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix,x-systemd.automount)
> 
> # fstrim -v /mnt/media
> fstrim: /mnt/media: the discard operation is not supported
> .
> 


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
       [not found]                     ` <2292eb8d-8357-227f-5448-d1d03b33c042@huawei.com>
@ 2020-03-25 13:58                       ` John
  2020-03-25 15:28                         ` Jaegeuk Kim
  0 siblings, 1 reply; 16+ messages in thread
From: John @ 2020-03-25 13:58 UTC (permalink / raw)
  To: Chao Yu, linux-f2fs-devel

On Tue, Mar 24, 2020 at 9:01 PM Chao Yu <yuchao0@huawei.com> wrote:
> I guess ssd should support discard, however I saw sdb was wrapped with device
> mapper, which may have different character, just want to check that whether
> device mapper disable the discard.
>
> If backup/restore is hard for you, how about let me add some logs on fstrim
> interface? then we could retry fstrim to see where we actually fail.

I have an older totally different SSD for testing that seems to support discard:
# hdparm -I /dev/sdc | grep TRIM
   * Data Set Management TRIM supported (limit 8 blocks)
   * Deterministic read ZEROs after TRIM

As I test, I created two f2fs partitions on this different SSD:
1) /dev/sdc2 normal F2FS
2) /dev/sdc3 encrypted with LUKS (dm-crypt) then formatted to F2FS

Results:
1) Regular F2FS
# fstrim -v /regular
/regular: 0 B (0 bytes) trimmed

2) Encrypted F2FS
# fstrim -v /encrypted
fstrim: /encrypted: the discard operation is not supported

Can we conclude that the device mapper is some how spoofing fstrim
into thinking the device doesn't support trim?  Happy to hear your
thoughts.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
  2020-03-25 13:58                       ` John
@ 2020-03-25 15:28                         ` Jaegeuk Kim
  2020-03-25 18:41                           ` John
  0 siblings, 1 reply; 16+ messages in thread
From: Jaegeuk Kim @ 2020-03-25 15:28 UTC (permalink / raw)
  To: John; +Cc: linux-f2fs-devel

On 03/25, John wrote:
> On Tue, Mar 24, 2020 at 9:01 PM Chao Yu <yuchao0@huawei.com> wrote:
> > I guess ssd should support discard, however I saw sdb was wrapped with device
> > mapper, which may have different character, just want to check that whether
> > device mapper disable the discard.
> >
> > If backup/restore is hard for you, how about let me add some logs on fstrim
> > interface? then we could retry fstrim to see where we actually fail.
> 
> I have an older totally different SSD for testing that seems to support discard:
> # hdparm -I /dev/sdc | grep TRIM
>    * Data Set Management TRIM supported (limit 8 blocks)
>    * Deterministic read ZEROs after TRIM
> 
> As I test, I created two f2fs partitions on this different SSD:
> 1) /dev/sdc2 normal F2FS
> 2) /dev/sdc3 encrypted with LUKS (dm-crypt) then formatted to F2FS
> 
> Results:
> 1) Regular F2FS
> # fstrim -v /regular
> /regular: 0 B (0 bytes) trimmed

This is normal.

> 
> 2) Encrypted F2FS
> # fstrim -v /encrypted
> fstrim: /encrypted: the discard operation is not supported

It seems dm-crypt has discard-related support, ie., "allow_discards", in ctrl.
But, FWIW, the target simply doesn't support discard at all.

# grep discards_supported drivers/md/*
drivers/md/dm-cache-target.c:	ti->discards_supported = true;
drivers/md/dm-clone-target.c:	ti->discards_supported = true;
drivers/md/dm-log-writes.c:	ti->discards_supported = true;
drivers/md/dm-table.c:	if (!tgt->num_discard_bios && tgt->discards_supported)
drivers/md/dm-table.c:		DMWARN("%s: %s: ignoring discards_supported because num_discard_bios is zero.",
drivers/md/dm-table.c:		 * 'discards_supported') or it relies on _all_ data devices having
drivers/md/dm-table.c:		if (!ti->discards_supported &&
drivers/md/dm-thin.c:		 * Setting 'discards_supported' circumvents the normal
drivers/md/dm-thin.c:		ti->discards_supported = true;
drivers/md/dm-thin.c:		ti->discards_supported = true;
drivers/md/dm-zoned-target.c:	ti->discards_supported = true;


> 
> Can we conclude that the device mapper is some how spoofing fstrim
> into thinking the device doesn't support trim?  Happy to hear your
> thoughts.
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
  2020-03-25 15:28                         ` Jaegeuk Kim
@ 2020-03-25 18:41                           ` John
  2020-03-25 19:04                             ` John
  0 siblings, 1 reply; 16+ messages in thread
From: John @ 2020-03-25 18:41 UTC (permalink / raw)
  To: Jaegeuk Kim; +Cc: linux-f2fs-devel

On Wed, Mar 25, 2020 at 11:29 AM Jaegeuk Kim <jaegeuk@kernel.org> wrote:
> It seems dm-crypt has discard-related support, ie., "allow_discards", in ctrl.
> But, FWIW, the target simply doesn't support discard at all.
>
> # grep discards_supported drivers/md/*
> drivers/md/dm-cache-target.c:   ti->discards_supported = true;
> drivers/md/dm-clone-target.c:   ti->discards_supported = true;
> drivers/md/dm-log-writes.c:     ti->discards_supported = true;
> drivers/md/dm-table.c:  if (!tgt->num_discard_bios && tgt->discards_supported)
> drivers/md/dm-table.c:          DMWARN("%s: %s: ignoring discards_supported because num_discard_bios is zero.",
> drivers/md/dm-table.c:           * 'discards_supported') or it relies on _all_ data devices having
> drivers/md/dm-table.c:          if (!ti->discards_supported &&
> drivers/md/dm-thin.c:            * Setting 'discards_supported' circumvents the normal
> drivers/md/dm-thin.c:           ti->discards_supported = true;
> drivers/md/dm-thin.c:           ti->discards_supported = true;
> drivers/md/dm-zoned-target.c:   ti->discards_supported = true;

I can confirm that it is true with an encrypted ext4 partition.  I get
the same error, "fstrim: /mnt/test: the discard operation is not
supported" when I try it there on the same device.  Unless there is a
good reason for it, not having discard on LUKS encrypted partitions
seems like a pretty serious omission.  Perhaps it is intentional.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
  2020-03-25 18:41                           ` John
@ 2020-03-25 19:04                             ` John
  2020-03-25 19:59                               ` Jaegeuk Kim
  0 siblings, 1 reply; 16+ messages in thread
From: John @ 2020-03-25 19:04 UTC (permalink / raw)
  To: Jaegeuk Kim, linux-f2fs-devel

On Wed, Mar 25, 2020 at 2:41 PM John wrote:
> I can confirm that it is true with an encrypted ext4 partition.  I get
> the same error, "fstrim: /mnt/test: the discard operation is not
> supported" when I try it there on the same device.  Unless there is a
> good reason for it, not having discard on LUKS encrypted partitions
> seems like a pretty serious omission.  Perhaps it is intentional.

I see now from searching that this is by design,
https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)

I added the "discard" option to the entry in /etc/crypttab and
rebooted. I am now able to get a successful run of fstrim on this F2FS
partition:

# fstrim -v /mnt/media
/mnt/media: 0 B (0 bytes) trimmed

Is it normal to return 0 bytes trimmed for F2FS partitions?  By
contrast, if I go to my test SSD, create a LUKS partition, open it
with the --allow-discards option to cryptsetup, format it to ext4,
mount that and then run fstrim on it, I am getting non-0 values for
fstrim when I run it:

# fstrim -v /mnt/test_crypt_ext4
/mnt/test_crypt_ext4: 3.9 GiB (4123463680 bytes) trimmed

So I think something still isn't quite right with F2FS over crypto_LUKS.

Thanks for the help!


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
  2020-03-25 19:04                             ` John
@ 2020-03-25 19:59                               ` Jaegeuk Kim
  2020-03-25 21:13                                 ` John
  0 siblings, 1 reply; 16+ messages in thread
From: Jaegeuk Kim @ 2020-03-25 19:59 UTC (permalink / raw)
  To: John; +Cc: linux-f2fs-devel

On 03/25, John wrote:
> On Wed, Mar 25, 2020 at 2:41 PM John wrote:
> > I can confirm that it is true with an encrypted ext4 partition.  I get
> > the same error, "fstrim: /mnt/test: the discard operation is not
> > supported" when I try it there on the same device.  Unless there is a
> > good reason for it, not having discard on LUKS encrypted partitions
> > seems like a pretty serious omission.  Perhaps it is intentional.
> 
> I see now from searching that this is by design,
> https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)
> 
> I added the "discard" option to the entry in /etc/crypttab and
> rebooted. I am now able to get a successful run of fstrim on this F2FS
> partition:
> 
> # fstrim -v /mnt/media
> /mnt/media: 0 B (0 bytes) trimmed
> 
> Is it normal to return 0 bytes trimmed for F2FS partitions?  By

It's normal, and that's why I asked -o nodiscard. The reason is F2FS creates
asynchronous discard thread to alleviate long discarding latency among RW IOs.
It keeps candidates in memory, and the thread issues them in idle time.

In that mode, when you do fstrim, F2FS collects all the discard candidates given
address space, and returns zero, since it didn't issue any discard command at
the moment.

But, if you set -o nodiscard, you can see the actual trimmed size, since F2FS
disabled the async discard thread and issue discard rightaway if device supports
it.

> contrast, if I go to my test SSD, create a LUKS partition, open it
> with the --allow-discards option to cryptsetup, format it to ext4,
> mount that and then run fstrim on it, I am getting non-0 values for
> fstrim when I run it:
> 
> # fstrim -v /mnt/test_crypt_ext4
> /mnt/test_crypt_ext4: 3.9 GiB (4123463680 bytes) trimmed
> 
> So I think something still isn't quite right with F2FS over crypto_LUKS.
> 
> Thanks for the help!


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions
  2020-03-25 19:59                               ` Jaegeuk Kim
@ 2020-03-25 21:13                                 ` John
  0 siblings, 0 replies; 16+ messages in thread
From: John @ 2020-03-25 21:13 UTC (permalink / raw)
  To: Jaegeuk Kim; +Cc: linux-f2fs-devel

On Wed, Mar 25, 2020 at 3:59 PM Jaegeuk Kim <jaegeuk@kernel.org> wrote:
> > Is it normal to return 0 bytes trimmed for F2FS partitions?  By
>
> It's normal, and that's why I asked -o nodiscard. The reason is F2FS creates
> asynchronous discard thread to alleviate long discarding latency among RW IOs.
> It keeps candidates in memory, and the thread issues them in idle time.

That is really good information.  Thanks for sharing it.  How long
does the async discard thread wait before it decides to check for idle
and does the actual discard operation?  I assume this mode is the
recommended way to use F2FS since you guys have it setup by default.
Please correct me if I am mistaken.

> In that mode, when you do fstrim, F2FS collects all the discard candidates given
> address space, and returns zero, since it didn't issue any discard command at
> the moment.
>
> But, if you set -o nodiscard, you can see the actual trimmed size, since F2FS
> disabled the async discard thread and issue discard rightaway if device supports
> it.

Also, I wanted to thank both you and and Chao for your helpful replies
in troubleshooting this.  So in summary for others happening across
this, discard/trim is disabled on LUKS by default; be sure to read the
Arch Wiki page I linked a few replies ago for details and for ways you
can enable it if you understand the security risks of doing so.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2020-03-25 21:13 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-14 18:09 [f2fs-dev] fstrim does not recognize FSVER=1.13 of F2FS partitions John
2020-03-16  1:24 ` Chao Yu
2020-03-16  9:52   ` John
2020-03-17  1:44     ` Chao Yu
2020-03-18 20:25       ` John
2020-03-23  4:11         ` Jaegeuk Kim
2020-03-23 10:27           ` John
2020-03-23 15:02             ` Jaegeuk Kim
2020-03-23 20:12               ` John
2020-03-24  2:32                 ` Chao Yu
     [not found]                   ` <CAO_nJAYWQWrWaQVfUmVpJGFtOeKKE76im-AkLUDTJm8DN4VAgA@mail.gmail.com>
     [not found]                     ` <2292eb8d-8357-227f-5448-d1d03b33c042@huawei.com>
2020-03-25 13:58                       ` John
2020-03-25 15:28                         ` Jaegeuk Kim
2020-03-25 18:41                           ` John
2020-03-25 19:04                             ` John
2020-03-25 19:59                               ` Jaegeuk Kim
2020-03-25 21:13                                 ` John

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).