Re: [PATCH 07/21] shmem: document how to "persist" data when using shmem_*file_setup

Matthew Wilcox
2024-01-29T15:57:04Z

On Sun, Jan 28, 2024 at 05:54:34PM +0100, Christoph Hellwig wrote:
> On Fri, Jan 26, 2024 at 03:49:30PM +0000, Matthew Wilcox wrote:
> > This doesn't quite make sense to me. Do you mean:
> >
> > * If the caller modifies data in the folio, it must call folio_mark_dirty()
> > * before unlocking the folio to ensure that the folio is not reclaimed.
> > * There is no equivalent to write_begin/write_end for shmem.
> >
> > (also this should go before the Return: section; the return section
> > should be the last thing in the kernel-doc)
>
> So the first sentence and moving the section makes total sense.
> The second sentence I don't think is very useful. write_begin/write_end
> are relaly just a way for generic_perform_write to do the space
> reservation and extending i_size and not really methods in the classic
> sense. They should go away from a_ops and certainly don't end up
> being mentioned in shmem.c.
>
> What I have now is this:
>
> If the caller modifies data in the folio, it must call folio_mark_dirty()
> before unlocking the folio to ensure that the folio is not reclaimed.
> These is no need to reserve space before calling folio_mark_dirty().

That's totally fine with me.

Could I trouble you to elaborate on what you'd like to see a filesystem
like ubifs do to replace write_begin/write_end? After my recent patches,
those are the only places in ubifs that have a struct page reference.
I've been holding off on converting those and writepage because we have
plans to eliminate them, but I'm not sure how much longer we can hold off.