for those who joined this discussion late, here are more details on the
network appliance snapshot capability that we are talking about emulating
(this duplicates some messages taht were sent a couple of weeks ago)
The Network appliance filers have a "snapshot" capability that works
somewhat similar to the following
1. when you take a snapshot the system makes a copy of all the inodes.
2. when a file is changed, the old inode and the block it points to are
left alone, the data is copied from the old block to a new block (with the
changes) and the current inode set is updated to match
the process of taking a snapshot is very fast and one it is taken the data
can be retreived as it existed at that time until the snapshot is deleted.
(the backup procedure for the network appliance takes a snapshot, backs it
up then deletes the snapshot)
This all happens on the same partition (although you can reserve some
space for snapshots, similar to how some disk space is reserved for root)
David Lang
On Fri, 13 Nov 1998, Riccardo Facchetti wrote:
> Date: Fri, 13 Nov 1998 09:42:41 +0100 (MET)
> From: Riccardo Facchetti <fizban@tin.it>
> To: Theodore Y. Ts'o <tytso@mit.edu>
> Cc: Mofeed Shahin <shahin@labf.org>, linux-kernel@vger.rutgers.edu
> Subject: Re: e2fsck...
>
> On Thu, 12 Nov 1998, Theodore Y. Ts'o wrote:
>
> [...]
> > Multics did allow on-line salvaging of volumes, and it is theoretically
> > possible to do such a thing. But it requires that the filesystem
> > checker lock out kernel changes, and the filesystem checker would have
> > to be in close communication with the kernel while it went about its
> > business. E2fsck and the kernel both don't have the necessary
> > infrastructure to do this today.
>
> I recall that recently someone (I don't remember who just right now)
> proposed some sort of snapshot device for filesystems. So that when you
> access a snapshot you lock the filesystem and you can backup it. The
> changes to the fs are recorded in a temporary partition (raw or e2fs or
> the-same-as-the-shapshotted ?) and the /dev/sda1snapshot is synced, locked
> and ready for backup (may be umounted ? Hmm ... I think better remounted
> readonly). This way you can even 'e2fsck /dev/sda1snapshot'. Filesystem
> snapshots seems a really good idea and the filesystem checker have not to
> be in close communication with the kernel while doing its job.
>
> Of course this raise a lot of other problems. For example what about
> eating up all the temporary partition ? You have plenty of space on the
> real partition but the temporary one is too little and fill up very fast.
> The result should be a filesystem full or the kernel is allowed to
> allocate more space on other partitions for saving the diff data ?
>
> Ciao,
> Riccardo.
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQEVAwUBNkx9zD7msCGEppcbAQFqcwgAuacVc6FR9fdmaoMnJvSdDlwRf2+w8IWD
sJtMe72Tov9uA/gZwJBqoLPVeZtIf4BOymk2Rp6/XhQh3EE63vwE1GHjaTEo70RL
6mNsmVXgeorEB0zbqpxe+f96TI11/zTvPR/937NS2g+bq1cuG7ejetDRfVce/YJF
NBqw1dktod4aB1wHxaA8vS8uG7xSGK4n2kD3H7qS+mrYk300qymoy5hCtnJBvW+J
y32vqmJsyr+SC69iMfUtAHT184dwDENbgGzqdO4PPhA6aM5b0i+j7MuyQZHUNA+E
UZY0Tq5ednf/Z/FvaqGTgSMREtTmS5RNNjygeuNHgqLUy9B4vxkVdg==
=2a26
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/