Re: [RFC] Remove NTFS kernel support

On Thu, 7 Feb 2008, M. Warner Losh wrote:

In message: <20080207.163454.-1471235838.imp@xxxxxxxxxx>
"M. Warner Losh" <imp@xxxxxxxxxx> writes:
: In message: <3bbf2fe10802070621h574f5d3kb4fbd86adbab11c@xxxxxxxxxxxxxx>
: "Attilio Rao" <attilio@xxxxxxxxxxx> writes:
: : 2008/2/7, Alfred Perlstein <alfred@xxxxxxxxxxx>:
: : > * Attilio Rao <attilio@xxxxxxxxxxx> [080207 06:13] wrote:
: : > > 2008/2/7, Andre Oppermann <andre@xxxxxxxxxxx>:
: : > > > 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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

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

Relevant Pages

  • My results of trying 9.0 live evaluation
    ... The first time I booted from the 9.0 CD, it attempted to install my Epson ... disconnected and it completed the boot operation reasonably fast. ... storage and ram disks. ... any of them said that the NTFS kernal mode was not installed. ...
    (alt.os.linux.suse)
  • NTFS 3.0 corrupting ability to use NTWKST 4.0 chkdsk ...
    ... that it would make to NTFS. ... >MS should be required by law to supply a corrective fix ... >version of NTFS which effectivly disables CHKDSK for NT ... >Service packs are NOT to change NTFS partition versions - ...
    (microsoft.public.win2000.file_system)
  • Re: Locking Computer Software
    ... > and you have your disks formatted using NTFS, ... DOS boot disks that can read ... This is hardly "very secure". ...
    (alt.computer.security)
  • Re: Comparison of NTFS/MFT recovery software?
    ... Scandisk.ini to automatically "fix" errors and delete recovered files ... how would NTFS ... - bad hardware issues *will* corrupt file systems ... awareness to prevent malware from writing directly to raw disk. ...
    (microsoft.public.windowsxp.hardware)
  • Re: Comparison of NTFS/MFT recovery software?
    ... Scandisk.ini to automatically "fix" errors and delete recovered files ... how would NTFS ... - bad hardware issues *will* corrupt file systems ... awareness to prevent malware from writing directly to raw disk. ...
    (microsoft.public.windowsxp.general)