Date: Sat, 26 Jun 2004 11:29:41 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Joe Schmoe <non_secure@yahoo.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: A few technical items on UFS2 and snapshots... Message-ID: <Pine.NEB.3.96L.1040626112040.46724K-100000@fledge.watson.org> In-Reply-To: <20040625211917.37738.qmail@web53302.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 25 Jun 2004, Joe Schmoe wrote:
> --- Oliver Fromme <olli@lurza.secnetix.de> wrote:
>
> > > 1. Is it dangerous to mount all 20 possible
> > filesystem snapshots and
> > > _leave them mounted_ to use at any time ?
> >
> > I don't think there is any danger, except that you
> > will run
> > out of disk space sooner or later.
>
> Every snapshot I have taken so far takes up zero space on the drive, or
> at least that is what `df` is telling me ... when I do an `ls -asl` in
> the directory with the snapshots, I can see each snapshot has a filesize
> equal to the size of the partition that was snapshotted, but again, `df`
> tells me they take up zero extra space. So where is the disconnect
> there ? How much space is the snapshot _really_ taking up, and how do I
> determine that ?
Snapshots are copy-on-write, so the amount of storage they actually take
grows as the file system it's snapshotting changes. You can see the
projected size of the snapshot using "ls -l", which will show you the size
of the image. You can see the allocated size using "du" or "ls -s". As
the file system diverges, the size of the snapshot grows: I've found a
particularly effective way to illustrate this is to delete files present
in the snapshot, because the space allocated to the files will be changed
from their inodes in the file system to the snapshot, so the amount of
free space may not change even though files are being deleted. If no
files or directories present in the snapshot are changed in the real file
system, the size of the snapshot will be stable.
So try this:
dd a 20mb file into /usr/tmp. Snapshot /usr. Measure the size of the
snapshot and free space. Delete the 20mb file. Now measure the size of
the snapshot and free space. The snapshot should have grown by 20mb (or
so), and the free space should remain the same. Now delete the snapshot,
and you have the 20mb back.
> > > 2. Related to the first question, it seems like I
> > am getting space
> > > out of nowher e ... that is, if I fill up a
> > drive, then make a
> > > snapshot, then erase the drive and fill it again,
> >
> > You cannot fill it up again, because the snapshot
> > still
> > takes up all the space. When you fill the drive and
> > make
> > a snapshot, erasing the drive will not free any
> > space.
>
> Is this really true ? Where did you read this ? (so I can go read it
> too...) And this goes back to my first question above - if the snapshot
> files all take up the same amount of space as the filesystem itself, but
> `df` does not show an increase in space when I make a snapshot, how do I
> tell what is _really_ going on ?
Think of if this way: if we didn't have the copy-on-write behavior, the
snapshot of the entire file system would immediately take up the file size
of all allocated space on the file system. Instead, we use copy-on-write
to describe the incremental changes between the state of the file system
when it was snapshotted and the current state. This means that at first,
when there are few differences, the snapshot is essentially "free" when it
comes to storage space. If your snapshots only last a short time relative
to data changes on the file system, they are deleted and little space goes
back or forth. If they last longer, or data moves faster, they start to
cost storage as they describe the differences using more space.
Another way to think about it is this: snapshots are a special kind of
file. When you address an offset in the snapshot file, the file system
code presents you with a snapshot of a disk image associated with the file
system at the time of the snapshot. This is why you can mount it, dd it,
back it up, etc. Because it represents the differences, they will
frequently (at first) be small, but as the changes accumulate, the file
will appear to grow in storage requirements. Because the file is also in
the file system, the space it consumes is billed against the free space on
the file system.
> > > 3. When I mount a snapshot, as described in the
> > man page, but then
> > > later mount - uw the snapshot ( to make that a
> > writeable mount) and,
> > > say, touch a file or create a file in the mounted
> > snapshot ... what
> > > exactly am I doing ?
> >
> > You're getting EPERM ("operation not permitted"),
> > because
> > snapshots are always read-only.
>
> No, I'm not. Re-read the question - I am saying that after I mount the
> snapshot, I then remount it with -uw, making it writeable (with `mount
> -uw`), and then I can _successfully_ touch files inside that snapshot.
> SO what exactly am I doing then ? Have I ruined the snapshot ? Can it
> still be used ? What inodes and space get used when I touch files
> inside a write-mounted snapshot ? Should the ability to mount -uw a
> snapshot mount be removed (in the same way that there is an exception in
> the unlink system call that allows you to delete schg flagged snapshots)
> ??
If we're allowing a snapshot to be remounted read-write, that's a bug.
I'm not sure what the implications of the bug are. Could you file a PR
with the precise commands you use to reproduce it and an illustration of
performing a write to it, then e-mail me the PR number by private e-mail?
> Anyone else have comments on the above sequence ? Is that possible to
> have happen, or did I just dream it ?
I hope just dream, because that's not supposed to be allowed. If it is,
we need to fix it ASAP. :-)
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040626112040.46724K-100000>