Hi Matthew, > On 15 Jan 2024, at 14:49, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > 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. Thanks. I would have been happy to do that but it seems everyone else prefers to remove it so I have given my ack for that instead... Best regards, Anton -- Anton Altaparmakov <anton at tuxera.com> (replace at with @) Lead in File System Development, Tuxera Inc., http://www.tuxera.com/ Linux NTFS maintainer
