Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ZFS: A *nested* zfs down within a higher-up zfs: SNAPSHOT the top one, bot one done too?

19 views
Skip to first unread message

David Combs

unread,
Dec 26, 2009, 7:48:35 PM12/26/09
to
Suppose you're using zfs, and down under you create
another one, and stuff (files, dirs, etc) beneath it.

Heck, maybe even yet another zfs down within THAT one,
it also having stuff under it.

So, time to make a snapshot.

(1) Suppose I snapshot (just) the topmost one.

(I know what I'd *like* to happen -- but what
really does happen?

That is, does EVERYTHING get looked at and properly processed?)


(2) For the purpose of writing the COMPLETE snapshot (well, to
coin a term, let's call lit a "level 0" snapshot) that I
can write/save onto a (long) tape (and take off-sitei).

I can do that "level 0" one also via doing solely the TOP one?

Thanks,

David



Zfs..

unread,
Dec 26, 2009, 8:20:39 PM12/26/09
to
On Dec 27, 12:48 am, dkco...@panix.com (David Combs) wrote:
> Suppose you're using zfs, and down under you create
> another one, and stuff (files, dirs, etc) beneath it.
>
> Heck, maybe even yet another zfs down within THAT one,
> it also having stuff under it.
>
> So, time to make a snapshot.
>
> (1) Suppose I snapshot (just) the topmost one.
>
>    (I know what I'd *like* to happen -- but what
>     really does happen?  
>
>     That is, does EVERYTHING get looked at and properly processed?)

No the snapshot is per dataset so if you snapshot the top most vdev
then you get a snapshot of whats in that dataset not anything
underneath.

Each dataset is independent of the pool, although all the resources of
the pool are available to all the datasets all the time, this is
controlled via dataset quotas/reservations etc.

When you create a pool. you can mount this top level vdev and then all
you would need is one snapshot, however the beauty of zfs is that a
lot of the time you need to have control over a particular dataset so
the creation of mutiple hirearchial datasets is very appealing.

>
> (2) For the purpose of writing the COMPLETE snapshot (well, to
>     coin a term, let's call lit a "level 0" snapshot) that I
>     can write/save onto a (long) tape (and take off-sitei).
>
>     I can do that "level 0" one also via doing solely the TOP one?

No you need to snapshot each dataset and use send/recv to write it off
host.

Mark Musante

unread,
Dec 26, 2009, 10:56:36 PM12/26/09
to
You can do a recursive snapshot with "zfs snapshot -r <dataset>" and that will snapshot <dataset> and every dataset underneath it.

---
frmsrcurl: http://compgroups.net/comp.unix.solaris/ZFS-A-nested-zfs-down-within-a-higher-up-zfs-SNAPSHOT-the-top-one-bot-one-done

Zfs..

unread,
Dec 27, 2009, 9:48:57 AM12/27/09
to
On Dec 27, 3:56 am, Mark Musante <u...@compgroups.net/> wrote:
> You can do a recursive snapshot with "zfs snapshot -r <dataset>" and that will snapshot <dataset> and every dataset underneath it.
>
> ---
> frmsrcurl:http://compgroups.net/comp.unix.solaris/ZFS-A-nested-zfs-down-within-...

Will this give you just one snapshot though or multiple snapshots ?

I dont have access to a Solaris box at the minute to try this out !

Mark Musante

unread,
Dec 27, 2009, 10:33:51 AM12/27/09
to
It will be one snapshot per dataset, but you can use send/recv recursively as well, so you can treat them as a single snapshot, and generate a single stream to write to tape.

---
frmsrcurl: http://compgroups.net/comp.unix.solaris/ZFS-A-nested-zfs-down-within-a-higher-up-zfs-SNAPSHOT-the-top-one-bot-one-done

Andrew Gabriel

unread,
Dec 28, 2009, 5:24:18 PM12/28/09
to
In article <567d090a-851b-4b7d...@j19g2000yqk.googlegroups.com>,

"Zfs.." <cian.s...@gmail.com> writes:
> On Dec 27, 3:56�am, Mark Musante <u...@compgroups.net/> wrote:
>> You can do a recursive snapshot with "zfs snapshot -r <dataset>" and that will snapshot <dataset> and every dataset underneath it.
>>
> Will this give you just one snapshot though or multiple snapshots ?

One snapshot for each nested zfs filesystem.

The other thing about doing it this way is that all the snapshots
are taken at exactly the same point in time, not one after another.
So if you have one app using more than one of the filesystems, then
you won't get inconsistances between the snapshots of the separate
filesystems due to timing differences as there are none.

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

David Combs

unread,
Dec 30, 2009, 10:59:20 PM12/30/09
to
In article <HMOdne8_6c_C46rW...@giganews.com>,

So (considering ALL the responses to this thread thus far), for a one-user
machine, the really simplest (and foolproof, least chance of screwup) is
to have but ONE zfs, and snapshot THAT, and write IT to tape,
etc.

Myself -- knowing myself, that is -- having several zfs's
(via a a single top-level recursive snapshot)
around to write to tape -- seems like way to easy
to screw up, to forget to save, etc.

(A *professional* sysadmin, of course, might well do
it differently.)

So, before I cement myself into a design, does what I
propose for me, for my single-user machine, sound reasonable
enough?

SAFE enough?

Comments, please...


THANKS!

David


David Combs

unread,
Jan 4, 2010, 9:57:32 AM1/4/10
to
In article <hhh7io$qjl$1...@reader1.panix.com>,

If the other posts (ie warnings) in this thread are
"zfs: that's the way it works -- like it or not!", about
NOT being able to via a SINGLE top-level "level-0" zfs
snapshot (to later save to tape), and get *everything*,
INCLUDING NESTED ZFS'S AND *THEIR* SUBTREES, etc,

that far and away the SAFEST and MOST FOOLPROOF way to
go is to have only ONE zfs in the pool --

so I *can* via a *single* snapshot, get it ALL.


(Note that this is still just a simple ONE-user machine!)

Thanks!

David

(I didn't even suspect that nested zfs's caused the multitude
of complications of snappshotting, as detailed in the very
surprising but excellently informative posts earlier on
this same thread, until I saw those very posts.

Simply NO SUCH DOCUMENTATION (and implicit warnings) anywhere
else I've seen. (Why not? Sure seems to be **ESSENTIAL** info.)


OH -- maybe those of you who know people who are currently writing
texts on Solaris-10 and/or openSolaris -- ask them to include
this info, with work-around examples, in detail.


David


Ian Collins

unread,
Jan 4, 2010, 9:39:03 PM1/4/10
to
David Combs wrote:
> In article <HMOdne8_6c_C46rW...@giganews.com>,
> Mark Musante <us...@compgroups.net/> wrote:
>> It will be one snapshot per dataset, but you can use send/recv recursively as well, so you can treat them as a single snapshot, and generate a single stream to write to tape.
>>
>> ---
>> frmsrcurl: http://compgroups.net/comp.unix.solaris/ZFS-A-nested-zfs-down-within-a-higher-up-zfs-SNAPSHOT-the-top-one-bot-one-done
>
> So (considering ALL the responses to this thread thus far), for a one-user
> machine, the really simplest (and foolproof, least chance of screwup) is
> to have but ONE zfs, and snapshot THAT, and write IT to tape,
> etc.
>
> Myself -- knowing myself, that is -- having several zfs's
> (via a a single top-level recursive snapshot)
> around to write to tape -- seems like way to easy
> to screw up, to forget to save, etc.

Write what to tape and how?

--
Ian Collins

Ian Collins

unread,
Jan 4, 2010, 9:44:23 PM1/4/10
to
David Combs wrote:

> If the other posts (ie warnings) in this thread are
> "zfs: that's the way it works -- like it or not!", about
> NOT being able to via a SINGLE top-level "level-0" zfs
> snapshot (to later save to tape), and get *everything*,
> INCLUDING NESTED ZFS'S AND *THEIR* SUBTREES, etc,
>
> that far and away the SAFEST and MOST FOOLPROOF way to
> go is to have only ONE zfs in the pool --

What would you do with such a snapshot? You keep mentioning "save to
tape", but how would you do that with a snapshot?

> so I *can* via a *single* snapshot, get it ALL.

That's what recursive snapshots are for. That is the way zfs is designed.

> (I didn't even suspect that nested zfs's caused the multitude
> of complications of snappshotting, as detailed in the very
> surprising but excellently informative posts earlier on
> this same thread, until I saw those very posts.
>
> Simply NO SUCH DOCUMENTATION (and implicit warnings) anywhere
> else I've seen. (Why not? Sure seems to be **ESSENTIAL** info.)

It is all clearly documented in the zfs man page.

--
Ian Collins

Gary R. Schmidt

unread,
Jan 5, 2010, 9:23:42 AM1/5/10
to
David Combs wrote:
[SNIP]
'Tis not difficult, assuming the the top-level file system is called
"filesystem":

# zfs snapshot -r filesystem@YYYYMMDD
# zfs send -R filesystem@YYYYMMDD > /dev/rmt0
# zfs destroy -r filesystem@YYYYMMDD

Approximately as difficult as falling off a log - and all straight from
the zfs man page, (except I send the stream to a file on a USB disk).

Cheers,
Gary B-)

0 new messages