Ralph Corderoy wrote:
> Hi Jörg,
>
> > Well, the name of the mailing list is "bug-tar" and not "bug-gtar", so
> > people would assume that it is a general tar list and not just a gtar
> > specific list.
>
> But you omitted the address of the mailing list is bug-tar@gnu.org and
> thus most would e
Hi Jörg,
> Well, the name of the mailing list is "bug-tar" and not "bug-gtar", so
> people would assume that it is a general tar list and not just a gtar
> specific list.
But you omitted the address of the mailing list is bug-tar@gnu.org and
thus most would expect it to be centred on GNU's tar an
Paul Eggert wrote:
> The problem with this particular filesystem appears to be that it lies
> about inode numbers in its snapshots. I suppose GNU tar (and other
> programs) will have to add a flag to ignore inode numbers too. What a pain.
In case that all inode numbers are different, this file
On 06/22/2018 01:49 AM, Joerg Schilling wrote:
Reliable filesystem backups on the other side need to be based on snapshots an
snapshots need to create ephemeral st_dev values
Sure, but if you want that, gtar has --no-check-device; that works fine
with ephemeral st_dev.
The problem with this
>> ...
>> Pieter Bowman wrote:
>>
>> > The problem seems to be caused by the changing of the inode of the
>> > root of that filesystem. The inode for the test filesystem's root
>> > directory is 3, the inode for various snapshots are numbers like:
>> >
>> > 28147497177
>> > 281474976671479
Pieter Bowman wrote:
> The problem seems to be caused by the changing of the inode of the
> root of that filesystem. The inode for the test filesystem's root
> directory is 3, the inode for various snapshots are numbers like:
>
> 28147497177
> 281474976671479
> 281474976673971
So it seems t
>> ...
>> On 06/21/2018 09:53 AM, Andreas Dilger wrote:
>> > Keep your old snapshot around after you create the new one, and run
>> > "stat(1)" > on the same file in both snapshots to see if there are any
>> > other
>> differences > besides the device number that may be causing tar to think
Andreas Dilger wrote:
> Keep your old snapshot around after you create the new one, and run "stat(1)"
> on the same file in both snapshots to see if there are any other differences
> besides the device number that may be causing tar to think the file changed.
gtar likes to implement something th
On 06/21/2018 09:53 AM, Andreas Dilger wrote:
Keep your old snapshot around after you create the new one, and run "stat(1)" > on the same file in both snapshots to see if there are any other
differences > besides the device number that may be causing tar to think
the file changed.
Yes, this is
On Jun 21, 2018, at 9:23 AM, Pieter Bowman wrote:
>
> We have been using gnu tar with amanda to backup our ZFS filesystems
> on Solaris (both SPARC and x86) for more than 10 years. We take a ZFS
> snapshot (destroying the previous snapshot if it exists), run amanda
> pointing to the snapshot dir
Pieter Bowman wrote:
> We have been using gnu tar with amanda to backup our ZFS filesystems
> on Solaris (both SPARC and x86) for more than 10 years. We take a ZFS
Did you ever run a restore operation?
> snapshot (destroying the previous snapshot if it exists), run amanda
> pointing to the sna
11 matches
Mail list logo
