Hi Matthew,
> On 15 Jan 2024, at 14:49, Matthew Wilcox <wi...@in...> 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
|