From owner-freebsd-arch@FreeBSD.ORG Thu Feb 7 23:54:42 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 543EC16A41A; Thu, 7 Feb 2008 23:54:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id EA7AF13C465; Thu, 7 Feb 2008 23:54:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m17NoWFd093666; Thu, 7 Feb 2008 16:50:32 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 07 Feb 2008 16:53:16 -0700 (MST) Message-Id: <20080207.165316.1678770676.imp@bsdimp.com> To: attilio@freebsd.org From: "M. Warner Losh" In-Reply-To: <20080207.163454.-1471235838.imp@bsdimp.com> References: <20080207141820.GR99258@elvis.mu.org> <3bbf2fe10802070621h574f5d3kb4fbd86adbab11c@mail.gmail.com> <20080207.163454.-1471235838.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 08 Feb 2008 00:02:00 +0000 Cc: yar@freebsd.org, swhetzel@gmail.com, andre@freebsd.org, jeff@freebsd.org, alfred@freebsd.org, anderson@freebsd.org, freebsd-fs@freebsd.org, dougb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Remove NTFS kernel support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2008 23:54:42 -0000 In message: <20080207.163454.-1471235838.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <3bbf2fe10802070621h574f5d3kb4fbd86adbab11c@mail.gmail.com> : "Attilio Rao" writes: : : 2008/2/7, Alfred Perlstein : : : > * Attilio Rao [080207 06:13] wrote: : : > > 2008/2/7, Andre Oppermann : : : > > > 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. Warner