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
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
