[RFC] Remove NTFS kernel support

[Eric Anderson]

Jeff Roberson wrote:
> On Thu, 7 Feb 2008, M. Warner Losh wrote:
> 
>> In message: <20080207.163454.-1471235838.imp at bsdimp.com>
>>            "M. Warner Losh" <imp at bsdimp.com> writes:
>> : In message: <3bbf2fe10802070621h574f5d3kb4fbd86adbab11c at mail.gmail.com>
>> :             "Attilio Rao" <attilio at freebsd.org> writes:
>> : : 2008/2/7, Alfred Perlstein <alfred at freebsd.org>:
>> : : > * Attilio Rao <attilio at freebsd.org> [080207 06:13] wrote:
>> : : > > 2008/2/7, Andre Oppermann <andre at freebsd.org>:
>> : : > > > Eric Anderson wrote:
>> : : > > > > I think Alfred's point is really interesting.  How many 
>> people that
>> : : > > > > don't use it that say 'axe it' does it take to override 1 
>> person saying
>> : : > > > > 'keep it!'?
>> : : > > >
>> : : > > > The real question is how many people does it take to say 
>> 'I'll maintain
>> : : > > > it'?  Just one.  Without it, it will only bitrot as 
>> evidenced by Attilios
>> : : > > > question.  NTFS is currently broken, just not as obvious 
>> because WITNESS
>> : : > > > didn't track and enforce lockmgr locks.
>> : : > >
>> : : > > Andre catched exactly my point.
>> : : > > The big problem is that we have a list of several unmaintained 
>> fs.
>> : : > > NTFS is in this list. The support is not reliable, it is only
>> : : > > available in read mode and eventually bugged.
>> : : > > I'm not sure I want to keep this if nobody wants to maintain it.
>> : : >
>> : : > All I'm saying is that I think this is a bit premature considering
>> : : > the users.  Within less than 24hrs we've had a few users reporting
>> : : > in as users, I'm sure the fixes (now that we have some good 
>> assertions)
>> : : > are going to be trivial.
>> : : >
>> : : > Why not let it ferment/rot for a release cycle and then see what
>> : : > the story is?
>> : :
>> : : Obviously if we can fix it is better, but axing is an opportunity I
>> : : don't want to leave out and this is why I wanted to poll users about
>> : : this issue. Eventually, if an axing is decided, it won't happen in
>> : : short times but only once all situations for "migration" will be
>> : : probed and finished.
>> :
>> : WE SHOULD NOT AXE IT.  IT IS TOO USEFUL.  VERY RECENTLY IT WORKED VERY
>> : WELL.
>> :
>> : There's a lot of other systems in the tree that aren't nearly as
>> : useful that nobody is complaining about that are actually in much
>> : worse shape.
>>
>> OK.  I shouldn't have shouted.  My basic point is that ntfs worked
>> very recently, and therefore we owe it to ourselves to give it some
>> time to get fixed.  fuse is unknown, not even in head and the
>> performance characteristics between the two aren't known.  Also, I use
>> ntfs to recover data from "crashed" disks because it copes well with
>> bad spots on the disk.  None of the other filesystems in the tree does
>> this, and that makes it a very powerful tool for dealing with crashed
>> disks that others say are unrecoverable.
> 
> Not picking on anyone in particular, but let's keep in mind that this 
> was an enquiry not a real proposal to axe it right away.  I suggested 
> Attilio find out if there were users and clearly there are.  So there is 
> value in keeping this thing working and fuse isn't a sure bet.  We just 
> wanted to understand the situation before acting.
> 
> However, this is open source.  Some one needs to step up to the plate 
> and fix these bugs.  It's only 4,700 lines of code.  It shouldn't be 
> insurmountable for someone who has a passing understanding of VFS.
> 
> Some of the bugs were exposed by better asserts and witness support by 
> Attilio.  I don't think his effort to fix lockmgr should be hung up 
> trying to understand ntfs however unless he directly broke it.  It's 
> going to have to continue firing asserts until someone fixes it.
> 
> Also, ntfs is a strange bird compared to other filesystems.  Briefly 
> looking at it, there may be some subtle architectural problems with it. 
> For example, it creates 'ntnode' inodes that aren't associated with 
> vnodes and so have their own lifecycle management.  It is likely that 
> this is the source of the panics that I have heard of.
> 
> An eager volunteer might also consider making it MPSAFE to further 
> reduce the number of filesystems which require Giant so we can 
> eventually drop the hideous giant wrappers.



Are all the known bugs entered into gnats already?

Eric