On Tue, Jan 21, 2020 at 10:09:51PM -0800, Jerome Glisse wrote: > On Wed, Jan 22, 2020 at 01:52:26PM +0800, Gao Xiang wrote: > > On Tue, Jan 21, 2020 at 09:21:18PM -0800, Jerome Glisse wrote: > > > > <snip> > > > > > > > > The block device code only need the mapping on io error and they are > > > different strategy depending on individual fs. fs using buffer_head > > > can easily be updated. For other they are different solution and they > > > can be updated one at a time with tailor solution. > > > > If I did't misunderstand, how about post-processing fs code without > > some buffer_head but page->private used as another way rather than > > a pointer? (Yes, some alternative ways exist such as hacking struct > > bio_vec...) > > The ultimate answer is that page write protection will not be allow > for some filesystem (that's how the patchset is designed in fact so > that things can be merge piecemeal). But they are many way to solve > the io error reporting and that's one of the thing i would like to get > input on. > > > > > I wonder the final plan on this from the community, learn new rule > > and adapt my code anyway.. But in my opinion, such reserve way > > (page->mapping likewise) is helpful in many respects, I'm not sure > > we could totally get around all cases without it elegantly... > > I still need to go read what it is you are trying to achieve. But i > do not see any reason to remove page->mapping I could say it's a huge project :) and I mean there may be some other options to "insert a pointer directly or indirectly to struct page. " However, I agree the current page->mapping rule is complicated to be sorted out in words and make full use it :) Thanks, Gao Xiang
