From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id F383A13838B for ; Sun, 7 Sep 2014 00:28:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 721FBE091A; Sun, 7 Sep 2014 00:28:04 +0000 (UTC) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4E00DE08F0 for ; Sun, 7 Sep 2014 00:28:03 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id f51so1981536qge.17 for ; Sat, 06 Sep 2014 17:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=FS1Loh5K2XdKhl66vnZyjk6qxTW4XeQsIaAbXxoogzE=; b=fE00l3POMwMMecwUcaVmVO6fbc6Kvj6rUOpkoDRaQoXT7zZgtdVo4iPxR/i1OFhk54 7goqWyXbIrxM+XNxTnBdhooRmkFUVBhtG5XDobjxwc1MZVHIHmk2nq7IYhQTmkMDpq/G qOjhllp6QShQNhVG/qhoRc6f17twEHVZLwB65njsG5qsaea8kDk4UdcBqPwL8xFwb0Vt wzQYFWx9dzqiPuNQk3U/YtQ8W3ZJwrS553DuEJw8o2XKzBrRNcZCwHIF1cGSjbexcFbc HLGoS5VJ1pfQizG8kK9TgZq+gGzN3gPGiZl7GePg2THhD98Fru9rn52xZNx/gKHGM8pu Up7A== X-Received: by 10.229.137.131 with SMTP id w3mr30519701qct.23.1410049682369; Sat, 06 Sep 2014 17:28:02 -0700 (PDT) Received: from [192.168.2.5] (adsl-74-240-55-140.jan.bellsouth.net. [74.240.55.140]) by mx.google.com with ESMTPSA id i93sm4107015qgd.43.2014.09.06.17.28.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Sep 2014 17:28:01 -0700 (PDT) Message-ID: <540BA691.9080508@gmail.com> Date: Sat, 06 Sep 2014 19:28:01 -0500 From: Dale User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: MBR partition References: <20140906030219.GR7971@syscon7> <20140906031059.GS7971@syscon7> <540AA690.1090905@fastmail.co.uk> <20140906104456.GA23438@syscon7> <540B02AA.60401@gmail.com> <540B0417.9010401@gmail.com> <540B7471.4020601@fastmail.co.uk> In-Reply-To: <540B7471.4020601@fastmail.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: 909f18ac-2ef6-4ef6-b27a-02d7369708fe X-Archives-Hash: 23279a07e1f7a4383e24c6ea6b07d9e2 Kerin Millar wrote: > On 06/09/2014 13:54, Alan McKinnon wrote: >> On 06/09/2014 14:48, Dale wrote: >>> James wrote: >>>> Joseph gmail.com> writes: >>>> >>>>> Thank you for the information. >>>>> I'll continue on Monday and let you know. If it will not boot >>>>> with sector >>>> starting at 2048, I will >>>>> re-partition /boot sda1 to start at 63. >>>> >>>> Take some time to research and reflect on your needs (desires?) >>>> about which file system to use. (ext 2,4) is always popular and safe. >>>> Some are very happy with BTRFS and there are many other interesting >>>> choices (ZFS, XFS, etc etc)...... >>>> >>>> There is no best solution; but the EXT family offers tried and proven >>>> options. YMMV. >>>> >>>> >>>> hth, >>>> James >>>> >>> >>> I'm not sure if it is ZFS or XFS but I seem to recall one of those does >>> not like sudden shutdowns, such as a power failure. Maybe that has >>> changed since I last tried whichever one it is that has that issue. If >>> you have a UPS tho, shouldn't be so much of a problem, unless your >>> power >>> supply goes out. >> >> XFS. >> >> It was designed by SGI for their video rendeing workstations back in the >> day and used very aggressive caching to get enormous throughput. It was >> also brilliant at dealing with directories containing thousands of small >> files - not unusual when dealing with video editing. >> >> However, it was also designed for environments where the power is >> guaranteed to never go off (which explains why they decided to go with >> such aggressive caching). If you use it in environments where powerouts >> are not guaranteed to not happen, well...... > > Well what? It's no less reliable than other filesystems that employ > delayed allocation (any modern filesystem worth of note). Over recent > years, I use both XFS and ext4 extensively in production and have > found the former trumps the latter in reliability. > > While I like them both, I predicate this assertion mainly on some of > the silly bugs that I have seen crop up in the ext4 codebase and the > unedifying commentary that has occasionally ensued. From reading the > XFS list and my own experience, I have formed the opinion that the > maintainers are more stringent in matters of QA and regression testing > and more mature in matters of public debate. I also believe that > regressions in stability are virtually unheard of, whereas regressions > in performance are identified quickly and taken very seriously [1]. > > The worst thing I could say about XFS is that it was comparatively > slow until the introduction of delayed logging (an idea taken from > ext3). [2] [3]. Nowadays, it is on a par with ext4 and, in some cases, > scales better. It is also one of the few filesystems besides ZFS that > can dynamically allocate inodes. > <> > --Kerin > > [1] > http://www.percona.com/blog/2012/03/15/ext4-vs-xfs-on-ssd/#comment-903938 > [2] > https://www.kernel.org/doc/Documentation/filesystems/xfs-delayed-logging-design.txt > [3] https://www.youtube.com/watch?v=FegjLbCnoBw > > The point I was making in my comment was about if the power fails without a proper shutdown. When I used it a long time ago, it worked fine, until there was a sudden power loss. That is when problems pop up. If a person has a UPS, should be good to go. Dale :-) :-)