From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ric Wheeler Subject: Re: topics for the file system mini-summit Date: Sat, 03 Jun 2006 09:50:16 -0400 Message-ID: <44819398.4030603@emc.com> References: <44762552.8000906@emc.com> <20060601021908.GL10420@goober> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, Arjan van de Ven Return-path: Received: from mexforward.lss.emc.com ([128.222.32.20]:37053 "EHLO mexforward.lss.emc.com") by vger.kernel.org with ESMTP id S1750837AbWFCN7Q (ORCPT ); Sat, 3 Jun 2006 09:59:16 -0400 To: Valerie Henson In-Reply-To: <20060601021908.GL10420@goober> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Valerie Henson wrote: >On Thu, May 25, 2006 at 02:44:50PM -0700, Ric Wheeler wrote: > > >> (1) repair/fsck time can take hours or even days depending on the >>health of the file system and its underlying disk as well as the number >>of files. This does not work well for large servers and is a disaster >>for "appliances" that need to run these commands buried deep in some >>data center without a person watching... >> (2) most file system performance testing is done on "pristine" file >>systems with very few files. Performance over time, especially with >>very high file counts, suffers very noticeable performance degradation >>with very large file systems. >> (3) very poor fault containment for these very large devices - it >>would be great to be able to ride through a failure of a segment of the >>underlying storage without taking down the whole file system. >> >>The obvious alternative to this is to break up these big disks into >>multiple small file systems, but there again we hit several issues. >> >> > >1 and 3 are some of my main concerns, and what I want to focus a lot >of the workshop discussion on. I view the question as: How do we keep >file system management simple while splitting the underlying storage >into isolated failure domains that can be repaired individually >online? (Say that three times fast.) Just splitting up into multiple >file systems only solves the second problem, and only if you have >forced umount, as you noted. > > > > Any thoughts about what the right semantics are for properly doing a forced unmount and how whether it is doable near term (as opposed to the more strategic/long term issues laid out in this thread) ? ric