Re: [PATCH] ovl: consistent behavior for immutable/append-only inodes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 11 Jun 2021 at 10:37, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> On Fri, Jun 11, 2021 at 10:55 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> >
> > On Fri, 11 Jun 2021 at 09:31, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> >
> > >
> > > Taking a step back.
> > >
> > > The main problem this is trying to solve is losing persistent inode flags
> > > on copy-up.
> > >
> > > If this was just NOATIME and SYNC the solution would have been
> > > simple - copy up the flags along with other metadata we copy up.
> > >
> > > We wouldn't even need to limit ourselves to the 4 vfs inode flags
> > > in ovl_copyflags(). We could add the the copied up flags more
> > > fs specific flags that we know to be safe and rational to copy
> > > such as NOCOW, NODUMP and DIRSYNC.
> > >
> > > The secondary problem is that copying IMMUTABLE/APPEND
> > > to upper inode on copy up is not an option, so the solution is to
> > > store those properties in an xattr.
> > >
> > > I think we should split the solution to the primary and secondary
> > > problems and avoid an over-designed generic future extendable
> > > xflags xattr feature.
> > >
> > > So I am leaning towards a more focused solution for
> > > IMMUTABLE/APPEND in the form of either two boolean
> > > xattr overlay.{immutable,appendonly} or one single bytes
> > > xattr overlay.protected.
> >
> > Makes sense.
> >
> > Not sure how you'd make it single byte and user friendly at the same
> > time. I.e. how'd you represent +ia?.   Otherwise I'm fine with either.
> >
>
> I had not considered user friendliness.
> I was thinking about the lower byte of i_flags.
> I can go with text format as planned for xflags
> but with no need for the fixed positions of letters.
> This format will be compatible with chattr so easy
> for script that "offline merge" overlay upper to lower.

Okay, let's do that, then.

Thanks,
Miklos



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux