> On Sun, 23 Aug 2009, Daniel Carosone wrote:
> > Userland tools to read and verify a stream, without
> having to play
> > it into a pool (seek and io overhead) could really
> help here.
>
> This assumes that the problem is data corruption of
> the stream, which
> could occur anywhere, even on
On Sun, 23 Aug 2009, Edward Ned Harvey wrote:
It makes no sense to attempt setting perms on a symlink. The perms are
determined by the actual file. The symlink is just another name for the
file itself. If you want to change perms of the file, change the perms of
the file.
Actually it does m
> >How can I prevent /usr/bin/chmod from following symbolic links? I
> can't find any
> >-P option in the documentation (and it doesn't work either..).
> > Maybe find can be used in some way?
>
>
> Not possible; in Solaris we don't have a lchmod(2) system call which
> makes
> adding a chmod optio
> zfs send -Rv rp...@0908 > /net/remote/rpool/snaps/rpool.0908
The recommended thing is to "zfs send | zfs receive" ... or more likely,
"zfs send | ssh somehost 'zfs receive'" You should ensure the source and
destination OSes are precisely the same version, because then you're assured
the zfs se
On Sun, 23 Aug 2009, Daniel Carosone wrote:
Userland tools to read and verify a stream, without having to play
it into a pool (seek and io overhead) could really help here.
This assumes that the problem is data corruption of the stream, which
could occur anywhere, even on the originating ho
> Save the data to a file stored in zfs. Then you are
> covered. :-)
Only if the stream was also separately covered in transit.
While you want in-transit protection regardless, "zfs recv"ing the stream into
a pool validates that it was not damaged in transit, as well as giving you
at-rest prot
On Sun, 23 Aug 2009, Daniel Carosone wrote:
However, the present behaviour is also useful: often when sending
streams you want to recompress, such as when sending a production
uncompressed dataset to a compressed backup/replica site.
If the receiving filesystem uses a different compression
> I have a gzip-9 compressed filesystem that I want to
> backup to a remote system and would prefer
> not to have to recompress everything
> again at such great computation expense.
This would be nice, and a similar desire applies to upcoming streams after
zfs-crypto lands.
However, the presen
On Sun, 23 Aug 2009, Ross wrote:
God knows, I've just checked the docs online and they make no mention of it
either:
http://docs.sun.com/app/docs/doc/819-5461/gbchx?a=view
This looks to me like a serious omission in the documentation.
Saving a send stream to file goes contrary to all the advi
God knows, I've just checked the docs online and they make no mention of it
either:
http://docs.sun.com/app/docs/doc/819-5461/gbchx?a=view
This looks to me like a serious omission in the documentation. Saving a send
stream to file goes contrary to all the advice I've ever seen posted on these
On Sun, 23 Aug 2009 09:54:07 PDT
Ross wrote:
> If you really want to store a backup, create another ZFS filesystem
> somewhere and do a send/receive into it. Please don't try to dump
> zfs send to a file and store the results.
If this is true than WHY does SUN advice on creating a zfs send to a
Ok, you *can* do this, but "zfs send" is *not* a backup mechanism. That
warning is all over the documentation, and for good reason.
ZFS send is not a guaranteed stable format, it is quite possible that upgrades
will leave you unable to receive that file, essentially leaving it unreadable.
Also
>Hello!
>
>How can I prevent /usr/bin/chmod from following symbolic links? I can't find
>any
>-P option in the documentation (and it doesn't work either..).
> Maybe find can be used in some way?
Not possible; in Solaris we don't have a lchmod(2) system call which makes
adding a chmod option (l
On Sun, 23 Aug 2009, Ross Walker wrote:
O_DIRECT does just that, with or without barriers, it flushes on each
write, with an ever so slight delay to allow the queue to coalesce writes.
My bad O_DIRECT does NOT do that, it just goes direct to the driver bypassing
page cache. Allows for low la
On Aug 23, 2009, at 9:59 AM, Ross Walker wrote:
On Aug 23, 2009, at 12:11 AM, Tristan Ball > wrote:
Ross Walker wrote:
[snip]
We turned up our X4540s, and this same tar unpack took over 17
minutes! We disabled the ZIL for testing, and we dropped this
to under 1 minute. With the X
On Aug 23, 2009, at 12:11 AM, Tristan Ball > wrote:
Ross Walker wrote:
[snip]
We turned up our X4540s, and this same tar unpack took over 17
minutes! We disabled the ZIL for testing, and we dropped this to
under 1 minute. With the X25-E as a slog, we were able to run
this test in
Ok.. A kind-of hybrid chmod then :)
Until you can figure out how to implement it, I probably have to do it this
way. Not too much extra work :)
find /backup/clients -type fd -exec /usr/bin/chmod -R
A=group:backup-owners:full_set:file_inherit/dir_inherit:allow {} \;
--
This message posted from
On Sun, 23 Aug 2009 13:15:37 +0200
joerg.schill...@fokus.fraunhofer.de (Joerg Schilling) wrote:
> dick hoogendijk wrote:
>
> > FULL backup to a file
> > zfs snapshot -r rp...@0908
> > zfs send -Rv rp...@0908 > /net/remote/rpool/snaps/rpool.0908
> >
> > INCREMENTAL backup to a file
> > zfs snapsh
dick hoogendijk wrote:
> FULL backup to a file
> zfs snapshot -r rp...@0908
> zfs send -Rv rp...@0908 > /net/remote/rpool/snaps/rpool.0908
>
> INCREMENTAL backup to a file
> zfs snapshot -i rp...@0908 rp...@090822
> zfs send -Rv rp...@090822 > /net/remote/rpool/snaps/rpool.090822
>
> As I underst
FULL backup to a file
zfs snapshot -r rp...@0908
zfs send -Rv rp...@0908 > /net/remote/rpool/snaps/rpool.0908
INCREMENTAL backup to a file
zfs snapshot -i rp...@0908 rp...@090822
zfs send -Rv rp...@090822 > /net/remote/rpool/snaps/rpool.090822
As I understand the latter gives a file with changes
Hi Harry.
Glad to hear you solved the problem. As soon as I saw that Quicktime's
error I thought about permissions. Unfortunately I sort of got used to
it. To follow on this discussion, I think there's something strange
here. It might simply be a Quicktime idiosyncrasy, which is chocking
onto thos
21 matches
Mail list logo
