On Mon, Jul 31, 2017, at 02:23 PM, Darrick J. Wong wrote:
> I don't think F_SEAL_{SHRINK,GROW} prevents reflinking or CoW of file data,
> which are two things that cannot happen under S_IOMAP_IMMUTABLE that
> aren't size changes. From the implementation it looks like shrink and
> grow are only supposed to disallow changes to i_size, not i_blocks (or
> the file block map).
True.
> Then again, I suppose F_SEAL_* only work on shmem, so maybe it simply
> isn't defined for any other filesystem...? e.g. it doesn't prohibit
> reflink, but the only fs implementing seals doesn't support reflink.
>
> <shrug>
>
> Seals cannot be removed, which is too strict for the S_IOMAP_IMMUTABLE
> user cases being presented.
To be clear, the set of use cases is swap files and DAX, right? Or is there anything else?
I can't imagine why anyone would want to turn a swap file back into a regular file.
I haven't fully followed DAX, but I'd take your word for it if people want to
be able to remove the flag after.
Anyways, I think your broader point is right; the use cases are different enough
that it doesn't make sense to try to add S_CONTENT_IMMUTABLE (or however
one decides to call it) at the same time.
