linux-kernel - Re: [RFC PATCH v5 06/10] ovl: implement overlayfs' ->write

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]

Date:   Tue, 30 Nov 2021 21:04:59 +0200
From:   Amir Goldstein <amir73il@...il.com>
To:     Chengguang Xu <cgxu519@...ernel.net>
Cc:     Jan Kara <jack@...e.cz>, Miklos Szeredi <miklos@...redi.hu>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        overlayfs <linux-unionfs@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        ronyjin <ronyjin@...cent.com>,
        charliecgxu <charliecgxu@...cent.com>,
        Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [RFC PATCH v5 06/10] ovl: implement overlayfs' ->write_inode operation

>  > I was thinking about this a bit more and I don't think I buy this
>  > explanation. What I rather think is happening is that real work for syncfs
>  > (writeback_inodes_sb() and sync_inodes_sb() calls) gets offloaded to a flush
>  > worker. E.g. writeback_inodes_sb() ends up calling
>  > __writeback_inodes_sb_nr() which does:
>  >
>  > bdi_split_work_to_wbs()
>  > wb_wait_for_completion()
>  >
>  > So you don't see the work done in the times accounted to your test
>  > program. But in practice the flush worker is indeed burning 1.3s worth of
>  > CPU to scan the 1 million inode list and do nothing.
>  >
>
> That makes sense. However, in real container use case,  the upper dir is always empty,
> so I don't think there is meaningful difference compare to accurately marking overlay
> inode dirty.
>

It's true the that is a very common case, but...

> I'm not very familiar with other use cases of overlayfs except container, should we consider
> other use cases? Maybe we can also ignore the cpu burden because those use cases don't
> have density deployment like container.
>

metacopy feature was developed for the use case of a container
that chowns all the files in the lower image.

In that case, which is now also quite common, all the overlay inodes are
upper inodes.

What about only re-mark overlay inode dirty if upper inode is dirty or is
writeably mmapped.
For other cases, it is easy to know when overlay inode becomes dirty?
Didn't you already try this?

Thanks,
Amir.