[RFC] Remove NTFS kernel support

[Jeff Roberson]

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.

Cheers,
Jeff


>
> Warner
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>