From owner-freebsd-fs@FreeBSD.ORG Wed Nov 2 14:14:57 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FB331065672 for ; Wed, 2 Nov 2011 14:14:57 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 099E58FC1A for ; Wed, 2 Nov 2011 14:14:56 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pA2EEZ4A037612 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 Nov 2011 16:14:41 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EB1504B.3080107@digsys.bg> Date: Wed, 02 Nov 2011 16:14:35 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Lee Dilkie References: <20111102131311.GA56941@icarus.home.lan> <4EB1476A.3070204@digsys.bg> <4EB14A47.8010107@Dilkie.com> In-Reply-To: <4EB14A47.8010107@Dilkie.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Default inode number too low in FFS nowadays? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 14:14:57 -0000 On 02.11.11 15:48, Lee Dilkie wrote: > > On 11/2/2011 1:36 PM, Daniel Kalchev wrote: >> >> >> On 02.11.11 15:13, Jeremy Chadwick wrote: >>> On Wed, Nov 02, 2011 at 12:57:33PM +0100, Borja Marcos wrote: >>>> Today I?ve come across an issue long ago forgotten :) Running out >>>> of i-nodes. >>> >> Just for the completeness of it, one would use ZFS and be done with >> this issue. :-) > > Are you suggesting that ZFS be the default FS? Not really. Perhaps we might think about something like this in 10.0 or 11.0 -- today too many people are wary of ZFS and there are already trivial ways to have ZFS-only FreeBSD install - so no need to hurry. > My only concern with ZFS is that it still appears to be in flux and > have some issues. I don't know, from monitoring this list, if those > are issues that heavy load users experience and ZFS is as stable as > UFS or if it isn't. I just know I see issues being raised. > Personally, I have two issues with ZFS: memory use and ... that it exposes very quickly bad hardware. I am currently at something like ~85% of my systems farm converted to ZFS-only. In the process, too many components proved to be bad. Disks, that previously were 'wonderful', display CRC errors in ZFS. Guess what --- these disks were happily reading/writing garbage with UFS and nobody ever noticed! This is a serious "issue" with going to ZFS .. that has me prompted to convert any active system to use ZFS-only, although that would require much more resources memory-wise. Another issue I have with ZFS is that it is not (yet) trivial to use for read-only installs, especially on the root. I have a multitude of systems that mount all their 'system' partitions read-only (UFS) and only data partitions are writable. I have yet to discover how one does this with ZFS only. Yet another issue, more pronounced with v28 than with v15 is that when your zpool gets full, performance becomes abysmal. That is particularly bad for systems that are nearly full most of the time --- easily fixable with larger disks, I know.. Yet another issue with ZFS is that while the traditional UNIX partittioning semantics has been local (such as, partittions a,b,c on drive1 are different than partittions a,b,c on drive2), ZFS pool names are global. You cannot have two 'system' pools on the same system and that makes some historic habits difficult to apply. The same trouble is with GEOM/GPT labels too, so we may just have to grow up. Other than that, my experience with ZFS has been more than wonderful. Daniel