linux-ext4 - Re: Re: discard and data=writeback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFnufp0zZL04L5UF_TY7+n91FjktG6Bb0J2j0f3eomXdnHGQ4A@mail.gmail.com>
Date:   Wed, 30 Dec 2020 16:16:42 +0100
From:   Matteo Croce <mcroce@...ux.microsoft.com>
To:     daejun7.park@...sung.com
Cc:     "tytso@....edu" <tytso@....edu>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: Re: discard and data=writeback

On Wed, Dec 30, 2020 at 6:21 AM Daejun Park <daejun7.park@...sung.com> wrote:
>
> > Hi,
> > >
> > > > # dmesg |grep EXT4-fs |tail -1
> > > > [ 1594.829833] EXT4-fs (nvme0n1p1): mounted filesystem with ordered
> > > > data mode. Opts: data=ordered,discard
> > > > # blktrace /dev/nvme0n1 & sleep 1 ; time rm -rf /media/linux-5.10/ ; kill $!
> > > > [1] 3032
> > > >
> > > > real    0m1.328s
> > > > user    0m0.063s
> > > > sys     0m1.231s
> > > > # === nvme0n1 ===
> > > >   CPU  0:                    0 events,        0 KiB data
> > > >   CPU  1:                    0 events,        0 KiB data
> > > >   CPU  2:                    0 events,        0 KiB data
> > > >   CPU  3:                 1461 events,       69 KiB data
> > > >   CPU  4:                    1 events,        1 KiB data
> > > >   CPU  5:                    0 events,        0 KiB data
> > > >   CPU  6:                    0 events,        0 KiB data
> > > >   CPU  7:                    0 events,        0 KiB data
> > > >   Total:                  1462 events (dropped 0),       69 KiB data
> > > >
> > > >
> > > > # dmesg |grep EXT4-fs |tail -1
> > > > [ 1734.837651] EXT4-fs (nvme0n1p1): mounted filesystem with writeback
> > > > data mode. Opts: data=writeback,discard
> > > > # blktrace /dev/nvme0n1 & sleep 1 ; time rm -rf /media/linux-5.10/ ; kill $!
> > > > [1] 3069
> > > >
> > > > real    1m30.273s
> > > > user    0m0.139s
> > > > sys     0m3.084s
> > > > # === nvme0n1 ===
> > > >   CPU  0:               133830 events,     6274 KiB data
> > > >   CPU  1:                21878 events,     1026 KiB data
> > > >   CPU  2:                46365 events,     2174 KiB data
> > > >   CPU  3:                98116 events,     4600 KiB data
> > > >   CPU  4:               290902 events,    13637 KiB data
> > > >   CPU  5:                10926 events,      513 KiB data
> > > >   CPU  6:                76861 events,     3603 KiB data
> > > >   CPU  7:                17855 events,      837 KiB data
> > > >   Total:                696733 events (dropped 0),    32660 KiB data
> > > >
> > >
> > > In this result, there is few IO in ordered mode.
> > >
> > > As I understand (please correct this if I am wrong), with writeback +
> > > discard, ext4_issue_discard is called immediately at each rm command.
> > > However, with ordered mode, ext4_issue_discard is called when end of
> > > committing a transaction to pace with the corresponding transaction.
> > > It means, they are not discarded yet.
> > >
> > > Even with ordered mode, if sync is called after rm command,
> > > ext4_issue_discard can be called due to transaction commit.
> > > So, I think you will get similar results form writeback mode with sync
> > > command.
> > >
> >
> > Hi,
> >
> > that's what I get with data=ordered if I issue a sync after the removal:
> >
> > # time rm -rf /media/linux-5.10/ ; sync ; kill $!
> >
> > real    0m1.569s
> > user    0m0.044s
> > sys     0m1.508s
> > #
> >  === nvme0n1 ===
> >  CPU  0:                10980 events,      515 KiB data
> >  CPU  1:                    0 events,        0 KiB data
> >  CPU  2:                    0 events,        0 KiB data
> >  CPU  3:                   26 events,        2 KiB data
> >  CPU  4:                 3601 events,      169 KiB data
> >  CPU  5:                    0 events,        0 KiB data
> >  CPU  6:                21786 events,     1022 KiB data
> >  CPU  7:                    0 events,        0 KiB data
> >  Total:                 36393 events (dropped 0),     1706 KiB data
> >
> > Still way less transactions than writeback.
> >
> The full trace you shared on this thread seems contains only on writeback
> mode. In the trace, discards are issued by each deletion file by rm.
>
> If you share the full trace on ordered mode, it will help we analyze the
> results. It is expected that number of discards will lower than writeback
> mode, because discards can be merged on ordered mode.
>

Hi,

I did the same blktrace with data=ordered,discard
Find it here:

https://drive.google.com/file/d/1gqffP9WPCME3_81xlXAQCiDlTK-Gqv4_/view?usp=sharing

Thanks,
-- 
per aspera ad upstream