From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 04:00:13 2005 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D37F016A4CF for ; Fri, 25 Feb 2005 04:00:13 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 211BF43D60 for ; Fri, 25 Feb 2005 04:00:13 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so317345wra for ; Thu, 24 Feb 2005 20:00:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=R0nGfbrv2XpeCK8AHgDS1LunSE820BAsYZvziqRCvaySsMpbJ+lbeqoYl126qzyogqA9XEgU3dHXKMkg85/SBL5vYTrOAHzrKrEjoiFOYjBqIXatfv1OTw0DCTYyp7EndYO1c11T7BNtc3XQeyzuY2j27lxE9EqM/1En7rQkjvI= Received: by 10.54.41.68 with SMTP id o68mr170692wro; Thu, 24 Feb 2005 20:00:12 -0800 (PST) Received: by 10.54.40.69 with HTTP; Thu, 24 Feb 2005 20:00:12 -0800 (PST) Message-ID: <2fd864e050224200035fa57ae@mail.gmail.com> Date: Thu, 24 Feb 2005 20:00:12 -0800 From: Astrodog To: Bruce Evans In-Reply-To: <20050225033921.C99633@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable References: <1109172559.702.13.camel@bsd.trippelsdorf.de> <421D052D.3030909@jonny.eng.br> <1109203614.577.5.camel@bsd.trippelsdorf.de> <2fd864e05022317214525e8f2@mail.gmail.com> <20050225033921.C99633@delplex.bde.org> cc: freebsd-amd64@freebsd.org cc: Markus Trippelsdorf Subject: Re: ext2 filesystem lockups X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Astrodog List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2005 04:00:14 -0000 On Fri, 25 Feb 2005 04:20:15 +1100 (EST), Bruce Evans wro= te: > On Wed, 23 Feb 2005, Astrodog wrote: >=20 > > On Thu, 24 Feb 2005 01:06:54 +0100, Markus Trippelsdorf > > wrote: > > > On Wed, 2005-02-23 at 19:35 -0300, Jo=E3o Carlos Mendes Lu=EDs wrote: > > > > David O'Brien wrote: > > > > > On Wed, Feb 23, 2005 at 04:29:19PM +0100, Markus Trippelsdorf wro= te: > > > > >>Which filesystem is recommended for multi-OS file exchange? > > > > > > > > > > I've heard enought reports of ext2 problems on 32-bit i386, that = I don't > > > > > trust it in situations that "have to work". By far the most wide= ly >=20 > I use it with no problems and trust it is easy to fix if some turn up. > I haven't tried it on amd64. >=20 > > > > > supported FS is vfat32 [mount_msdosfs(8)]. > > > > > > > > The last time I had to use msdosfs, on 4.* it was extremely slow > > > > compared to UFS on the same disk. Did this get better on 5.*? >=20 > The main slownesses in msdosfs are pessimal (random) block allocation > for the first block in a file, and non-use of some important system > features (clustering and VMIO). This has not been fixed in 5.x AFAIK. >=20 > > > I want to use the filesystem for my music collection, so I'm willing = to > > > trade fastness for reliability. >=20 > ffs is the most reliable of the read-write file systems in FreeBSD. > cd9660 is probably more reliable, and it is most portable, but it is > less convenient since it is read-only in the kernel. If you only need > to write under one OS then it is fairly safe to use ffs for writing > under FreeBSD and ext2fs for writing under Linux. >=20 > > vfat32/MSDOSFS is going to be the most supported, seeing as I can > > mount these types of filesystems on just about every OS out there. > > Regarding speed, there's a pretty big tradeoff, but even if it reduces > > drive I/O by %50, you're still above the speed of a 10/100 NIC, and >=20 > A big reduction is 99% :-). Reductions of 90% are common for small > files. >=20 > > certainly above the speed an MP3 streams at. (You're right at the > > limit, for DVD Video) In short, yes, it will be slower, but for the > > purposes of storing MP3s, and whatnot, the speed tradeoff is > > inconsequencial(sp), and it beats loosing everything every once in > > awhile. >=20 > But msdosfs is fundamentally very unreliable. Corrupted FATs give more > global problems than corrupted inodes. It doesn't help that the msdosfs > implementation cheats with FAT updates and does them fully asynchronously > (delayed up to 30+ seconds) using delayed writes unless you mount with > "-o sync" (which gives sync data too, and thus extreme slowness). So > msdosfs by default is closer to ffs with "-o async" and thus more > unreliable then necessary. >=20 > Bruce >=20 I suppose the real lesson here, is why would you want to use anything that doesn't support UFS? ;)