On 11/03/08 13:18, Philip Brown wrote:
Ok, I think I understand. You're going to be told
that ZFS send isn't a backup (and for these purposes
I definately agree), ...
Hmph. well, even for 'replication' type purposes, what I'm talking about is
quite useful.
Picture two remote systems, wh
> Ok, I think I understand. You're going to be told
> that ZFS send isn't a backup (and for these purposes
> I definately agree), ...
Hmph. well, even for 'replication' type purposes, what I'm talking about is
quite useful.
Picture two remote systems, which happen to have "mostly identical" dat
Ok, I think I understand. You're going to be told that ZFS send isn't a backup
(and for these purposes I definately agree), but if we ignore that this sounds
like you're talking about restoring a snapshot from an external media, and then
running a clone off that.
Clone's are already supported,
> If
> I'm interpreting correctly, you're talking about a
> couple of features, neither of which is in ZFS yet,
...
> 1. The ability to restore individual files from a
> snapshot, in the same way an entire snapshot is
> restored - simply using the blocks that are already
> stored.
>
> 2. The a
>> If the file still existed, would this be a case of redirecting the
>> file's top level block (dnode?) to the one from the snapshot? If the
>> file had been deleted, could you just copy that one block?
>>
>> Is it that simple, or is there a level of interaction between files
>> and snapshots tha
Ross Smith wrote:
>> Snapshots are not replacements for traditional backup/restore features.
>> If you need the latter, use what is currently available on the market.
>> -- richard
>>
>
> I'd actually say snapshots do a better job in some circumstances.
> Certainly they're being used that way
> Snapshots are not replacements for traditional backup/restore features.
> If you need the latter, use what is currently available on the market.
> -- richard
I'd actually say snapshots do a better job in some circumstances.
Certainly they're being used that way by the desktop team:
http://blogs.
Ross Smith wrote:
> Hi Darren,
>
> That's storing a dump of a snapshot on external media, but files
> within it are not directly accessible. The work Tim et all are doing
> is actually putting a live ZFS filesystem on external media and
> sending snapshots to it.
>
Cognitive disconnect, again.
Hi Darren,
That's storing a dump of a snapshot on external media, but files
within it are not directly accessible. The work Tim et all are doing
is actually putting a live ZFS filesystem on external media and
sending snapshots to it.
A live ZFS filesystem is far more useful (and reliable) than a
Ross wrote:
> Ok, I see where you're coming from now, but what you're talking about isn't
> zfs send / receive. If I'm interpreting correctly, you're talking about a
> couple of features, neither of which is in ZFS yet, and I'd need the input of
> more technical people to know if they are possi
Ok, I see where you're coming from now, but what you're talking about isn't zfs
send / receive. If I'm interpreting correctly, you're talking about a couple
of features, neither of which is in ZFS yet, and I'd need the input of more
technical people to know if they are possible.
1. The abilit
> Ah, there is a cognitive disconnect... more below.
>
> The cognitive disconnect is that snapshots are
> blocks, not files.
> Therefore, the snapshot may contain only changed
> portions of
> files and blocks from a single file may be spread
> across many
> different snapshots.
I was referring
Ah, there is a cognitive disconnect... more below.
Philip Brown wrote:
>> relling wrote:
>> This question makes no sense to me. Perhaps you can
>> rephrase?
>>
>>
>
> To take a really obnoxious case:
> lets say I have a 1 gigabyte filesystem. It has 1.5 gigabytes of physical
> disk allocate
> So, when I do a zfs receive, it would be "really
> nice", if there were some way for zfs to figure out,
> lets say, "recieve to a snapshot of the filesystem;
> then take advantage of the fact that it is a
> snapshot, to NOT write on disk, the 9 unaltered files
> that are in the snapshot; just all
> relling wrote:
> This question makes no sense to me. Perhaps you can
> rephrase?
>
To take a really obnoxious case:
lets say I have a 1 gigabyte filesystem. It has 1.5 gigabytes of physical disk
allocated to it (so it is 66% full).
It has 10x100meg files in it.
"Something bad happens", and I
> > 2.2 do a receive of an earlier zfs send, to
> either a snapshot or a "child" filesystem, and be
> efficient about disk space used. ie: have the recieve
> understand, "hey, I have that file already,
> completely intact, so I'm not going to waste space by
> storing it again".
> >
ZFS alread
Philip Brown wrote:
> I've recently started down the road of production use for zfs, and am hitting
> my head on some paradigm shifts. I'd like to clarify whether my understanding
> is correct, and/or whether there are better ways of doing things.
> I have one question for replication, and one qu
17 matches
Mail list logo
