From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 18:36:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 184A5C64; Fri, 14 Mar 2014 18:36:53 +0000 (UTC) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 78057E68; Fri, 14 Mar 2014 18:36:52 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id e49so1708726eek.17 for ; Fri, 14 Mar 2014 11:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DnVTALCmHnoD9gpWCVHCFJbKGSw3lsmBVljUeBVEN90=; b=j3fgUtHtR/SJz7IFzXB4ZsMXtaY9AwGo0MYj/PNeeG199yQ4Vha705M6biefVC+uIo cDXuIgv1uzCMwm/Eullt0g2FiRTqU2Kg5q4xtjLVoajAu+4C1+dW4PXpCAibCsVm8PAV qgbbvxLx4dkh1ouhbloTR1rj86rCM1OMjw7jheBQhpcVK7q83+2+kDjlR7epoJcSx0FG e++6QECMStNFhVQFtaiIr3NsIaz9yh3uLNBI2FhJ8OojX7Xt18/Wsj3Cy9L1YHVkQ3VW ANya6v3a0mXfQYZ2mJabNcmbDj4EWv0dYNG0nx3K524vphCAkrx9Au5nIKCbSXCPJ2be hh5A== X-Received: by 10.15.49.196 with SMTP id j44mr4308987eew.98.1394822210924; Fri, 14 Mar 2014 11:36:50 -0700 (PDT) Received: from strashydlo.home (adfi238.neoplus.adsl.tpnet.pl. [79.184.112.238]) by mx.google.com with ESMTPSA id i47sm18900649eeg.6.2014.03.14.11.36.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Mar 2014 11:36:50 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: GSoC proposition: multiplatform UFS2 driver Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <1394811577.1149.543.camel@revolution.hippie.lan> Date: Fri, 14 Mar 2014 19:36:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0405D29C-D74B-4343-82C7-57EA8BEEF370@FreeBSD.org> References: <20140314152732.0f6fdb02@gumby.homeunix.com> <1394811577.1149.543.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-hackers@FreeBSD.org, RW X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 18:36:53 -0000 Wiadomo=B6=E6 napisana przez Ian Lepore w dniu 14 mar 2014, o godz. = 16:39: > On Fri, 2014-03-14 at 15:27 +0000, RW wrote: >> On Thu, 13 Mar 2014 18:22:10 -0800 >> Dieter BSD wrote: >>=20 >>> Julio writes, >>>> That being said, I do not like the idea of using NetBSD's UFS2 >>>> code. It lacks Soft-Updates, which I consider to make FreeBSD UFS2 >>>> second only to ZFS in desirability. >>>=20 >>> FFS has been in production use for decades. ZFS is still wet behind >>> the ears. Older versions of NetBSD have soft updates, and they work >>> fine for me. I believe that NetBSD 6.0 is the first release without >>> soft updates. They claimed that soft updates was "too difficult" to >>> maintain. I find that soft updates are *essential* for data >>> integrity (I don't know *why*, I'm not a FFS guru).=20 >>=20 >> NetBSD didn't simply drop soft-updates, they replaced it with >> journalling, which is the approach used by practically all modern >> filesystems.=20 >>=20 >> A number of people on the questions list have said that they find >> UFS+SU to be considerably less robust than the journalled filesystems >> of other OS's. =20 Let me remind you that some other OS-es had problems such as truncation of files which were _not_ written (XFS), silently corrupting metadata = when there were too many files in a single directory (ext3), and panicing = instead of returning ENOSPC (btrfs). ;-> > What I've seen claimed is that UFS+SUJ is less robust. That's a very > different thing than UFS+SU. Journaling was nailed onto the side of = UFS > +SU as an afterthought, and it shows. Not really - it was developed rather recently, and with filesystems it = usually shows, but it's not "nailed onto the side": it complements SU operation by journalling the few things which SU doesn't really handle and which used to require background fsck. One problem with SU is that it depends on hardware not lying about write completion. Journalling filesystems usually just issue flushes instead.