Re: [PATCH] fs: Remove NTFS classic

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

 



On Mon, Jan 15, 2024 at 11:00:35AM +0000, Anton Altaparmakov wrote:
> Hi Matthew,
> 
> On 15/01/2024 07:20, Matthew Wilcox (Oracle) wrote:
> > The replacement, NTFS3, was merged over two years ago.  It is now time to
> > remove the original from the tree as it is the last user of several APIs,
> > and it is not worth changing.
> 
> It was my impression that people are complaining ntfs3 is causing a whole
> lot of problems including corrupting people's data.  Also, it appears the
> maintainer has basically disappeared after it got merged.

I'm not terribly happy with how the maintainer behaves either, but
you've also been missing in action for nine years (if we're counting
code authored by you) or two years (if a R-b is enough).

According to your documentation, you don't support creating new files
or directories, so I'd suggest that your code has never been put through
the xfstests wringer in the way that ntfs3 has.

> Also, which APIs are you referring to?  I can take a look into those.

The biggest one for me is the folio work.  Everywhere in your code that
use a struct page needs to be converted to a struct folio.  Support for
large folios is optional, and I wouldn't bother trying to add that.
Take a look at, eg, nilfs2, ext4, ext2, iomap, NFS, AFS for some
filesystems which have been (at least mostly) converted.

Any functions in mm/folio-compat.c should no longer be called.

If we're being really ambitious, filesystems should stop using the
buffer cache and switch to using iomap.  There's a lot of work going
on and unmaintained filesystems are holding us back.




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux