lkml.org 
[lkml]   [1998]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: File system snapshopts: how valuable?
Peter Benie <pjb1008@cam.ac.uk> wrote:
> Another nice feature of the NetApp FAServer is the fact that, modulo
> filesystem bugs, it does not need fscking. A new filesystem design
> ought to have this feature since fsck would take quite some time to
> run on a 50Gb disk.

This feature is in fact the central organizing principle of my file system.
(There's a great paper from Xerox PARC titled "Reimplementing the Cedar
File system Using Logging and Group Commit" which started the whole
thing.) These days, a news server that gets a full feed (including
alt.binaries,{pictures, warez, ...}) needs 120-180 GB of disk, and
had better be prepared to scale upwards.

Now, news data is not the world's most valuable to protect against loss, but
having the server down for many many hours while running fsck after a
power failure is unpleasant.

The feature that really fights with snapshots is the ability to run
a disk optimizer, which also includes the ability to resize file
systems at run time, which is also a useful feature.

These things require the ability to move a block of data that is
already on the disk and update all the pointers to it.
Without snapshots, the number of pointers to a given block is strictly
limited (essentially 1), so updating all the pointers is easy.
With snapshots, finding all the pointers gets much more complex.

In particular, if you need to clear out a section of the disk in order
to resize a partition, if you only have one pointer to each block, you
can just walk the entire file system (slow, but it's okay to take
several hours as long as the system stays up) and find all pointers to
blocks in the forbidden zone, and move those blocks. (Obviously, you
also avoid allocating any new blocks in the forbidden zone, but that's
easy.) When you've walked the entire file system, the forbidden zone
is empty (if the bitmap doesn't agree, the bitmap is wrong and you've
found an inconsistency in the file system).

If a block can have multiple pointers to it, this sort of thing
gets much more complicated. In the case of snapshots, you can
know that all pointers will share the same "virtual address" in various
snapshots (address spaces), so if you find a pointer from block #100
in inode #5432, then the other pointers will be from that inode in
other snapshots.

But some of the other copy-on-write tricks you could do (like virtual
copying of files, giving the same blocks a new virtual address within
the same file system) are not really possible. (Without massive
overhead for a lot of back-pointers.)

Um, unless someone has a really brilliant idea they want to share, that is.
(If you do, it would also be applicable to the Linux VM system, which
uses similar optimizations and thus has a similar problem moving
a page of memory from RAM to swap if there are multiple pointers to it.)
--
-Colin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.127 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site