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

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

 



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.




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux