On Tue, Jul 21, 2020 at 4:16 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Mon, Jul 20, 2020 at 6:16 PM Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > > > For building images containers folks need to sync upper layer. Their > > current plan is to use "syncfs upper/" because it is same as if overlay > > was mounted with sync=fs. But this syncs whole upper filesystem and > > not just upper of a particular overlayfs instance > > > > So idea was to provide sync=fs from the beginning and ask container > > folks to use this. So that in future if we can optimize sync=fs to > > sync selctive inodes, then container runtime will automatically > > benefit from it without any changes. It also reduces the chances > > of error on container runtime which fail to sync upper. Hence idea > > of sync=fs sounded appleaing to me. > > Not sure I understand the reason for sync=fs? Should it rather be > sync=shutdown? > Sounds good to me. > > > > Havid said that, I am open to dropping sync=fs for now, if you don't > > see the value at this point of time. > > At this point it doesn't add any usefulness, so let's just drop it. > > > > > > > Naming: I'm not at all convinced by any name having "sync" in it. I > > > think "sync=no" is about the implementation, not the functionality, > > > and so it's confusing. The functionality is better described by > > > "volatile" or "temporary". But I can live with sync=... if voted > > > down. > > > > I am fine with the name "volatile/temporary" for sync=off. > > How about needing "volatile" for all kinds of modes that reduce the > normal durability/integrity guarantees. Then additional "sync=foobar" > option to control the details? > Fine by me. Thanks, Amir.
