Re: topics for the file system mini-summit

[Ric Wheeler <ric@emc.com>]

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