Hello Will,
Monday, April 13, 2009, 6:44:47 PM, you wrote:
WM> On Mon, Apr 13, 2009 at 07:03, Robert Milkowski wrote:
>> Hello Daniel,
>>
>> Thursday, April 9, 2009, 3:35:07 PM, you wrote:
>>
>> DR> Jonathan schrieb:
OpenSolaris Forums wrote:
> if you have a snapshot of your files and r
Will Murnane schrieb:
Perhaps ZFS could do some very simplistic de-dup here: it has the
B-tree entry for the file in question when it goes to overwrite a
piece of it, so it could calculate the checksum of the new block and
see if it matches the checksum for the block it is overwriting. This
is a
On Mon, Apr 13, 2009 at 07:03, Robert Milkowski wrote:
> Hello Daniel,
>
> Thursday, April 9, 2009, 3:35:07 PM, you wrote:
>
> DR> Jonathan schrieb:
>>> OpenSolaris Forums wrote:
if you have a snapshot of your files and rsync the same files again,
you need to use "--inplace" rsync option
On Mon, 13 Apr 2009, Robert Milkowski wrote:
That's because without --inplace rsync will copy a file first, then
apply changes to it and if successful will remove the old file. So if
the old file is still in snapshot you will end-up with a new copy of
the file and the old copy being kept in a po
Hello Daniel,
Thursday, April 9, 2009, 3:35:07 PM, you wrote:
DR> Jonathan schrieb:
>> OpenSolaris Forums wrote:
>>> if you have a snapshot of your files and rsync the same files again,
>>> you need to use "--inplace" rsync option , otherwise completely new
>>> blocks will be allocated for the ne
On 10-Apr-09, at 2:03 PM, Harry Putnam wrote:
David Magda writes:
On Apr 7, 2009, at 16:43, OpenSolaris Forums wrote:
if you have a snapshot of your files and rsync the same files again,
you need to use "--inplace" rsync option , otherwise completely new
blocks will be allocated for the ne
David Magda writes:
> On Apr 7, 2009, at 16:43, OpenSolaris Forums wrote:
>
>> if you have a snapshot of your files and rsync the same files again,
>> you need to use "--inplace" rsync option , otherwise completely new
>> blocks will be allocated for the new files. that`s because rsync
>> will wr
On Apr 7, 2009, at 16:43, OpenSolaris Forums wrote:
if you have a snapshot of your files and rsync the same files again,
you need to use "--inplace" rsync option , otherwise completely new
blocks will be allocated for the new files. that`s because rsync
will write entirely new file and rena
Jonathan writes:
> It appears I may have misread the initial post. I don't really know how
> I misread it, but I think I missed the snapshot portion of the message
> and got confused. I understand the interaction between snapshots,
> rsync, and --inplace being discussed now.
I don't think you
OpenSolaris Forums writes:
> if you rsync data to zfs over existing files, you need to take
> something more into account:
>
> if you have a snapshot of your files and rsync the same files again,
> you need to use "--inplace" rsync option , otherwise completely new
> blocks will be allocated for
Greg Mason writes:
> Harry,
>
> ZFS will only compress data if it is able to gain more than 12% of
> space by compressing the data (I may be wrong on the exact
> percentage). If ZFS can't get get that 12% compression at least, it
> doesn't bother and will just store the block uncompressed.
>
> Al
Harry,
ZFS will only compress data if it is able to gain more than 12% of space
by compressing the data (I may be wrong on the exact percentage). If ZFS
can't get get that 12% compression at least, it doesn't bother and will
just store the block uncompressed.
Also, the default ZFS compressio
Daniel Rock wrote:
> Jonathan schrieb:
>> OpenSolaris Forums wrote:
>>> if you have a snapshot of your files and rsync the same files again,
>>> you need to use "--inplace" rsync option , otherwise completely new
>>> blocks will be allocated for the new files. that`s because rsync will
>>> write en
Jonathan schrieb:
OpenSolaris Forums wrote:
if you have a snapshot of your files and rsync the same files again,
you need to use "--inplace" rsync option , otherwise completely new
blocks will be allocated for the new files. that`s because rsync will
write entirely new file and rename it over th
OpenSolaris Forums wrote:
> if you rsync data to zfs over existing files, you need to take
> something more into account:
>
> if you have a snapshot of your files and rsync the same files again,
> you need to use "--inplace" rsync option , otherwise completely new
> blocks will be allocated for th
Jeff Bonwick writes:
>> > Yes, I made note of that in my OP on this thread. But is it enough to
>> > end up with 8gb of non-compressed files measuring 8gb on
>> > reiserfs(linux) and the same data showing nearly 9gb when copied to a
>> > zfs filesystem with compression on.
>>
>> whoops.. a he
if you rsync data to zfs over existing files, you need to take something more
into account:
if you have a snapshot of your files and rsync the same files again, you need
to use "--inplace" rsync option , otherwise completely new blocks will be
allocated for the new files. that`s because rsync w
> > Yes, I made note of that in my OP on this thread. But is it enough to
> > end up with 8gb of non-compressed files measuring 8gb on
> > reiserfs(linux) and the same data showing nearly 9gb when copied to a
> > zfs filesystem with compression on.
>
> whoops.. a hefty exaggeration it only show
Harry Putnam writes:
> Richard Elling writes:
>
>> Harry Putnam wrote:
>>> Robert Milkowski writes:
>>>
>>>
Then is block doesn't compress better than 12.5% it won't be
compressed at all. Then in zfs you need extra space for checksums, etc.
How did the OP came up with how
Richard Elling writes:
> Harry Putnam wrote:
>> Robert Milkowski writes:
>>
>>
>>> Then is block doesn't compress better than 12.5% it won't be
>>> compressed at all. Then in zfs you need extra space for checksums, etc.
>>>
>>> How did the OP came up with how much data is being used?
>>>
Harry Putnam wrote:
Robert Milkowski writes:
Then is block doesn't compress better than 12.5% it won't be
compressed at all. Then in zfs you need extra space for checksums, etc.
How did the OP came up with how much data is being used?
OP, just used `du -sh' at both ends of the trans
Robert Milkowski writes:
> Then is block doesn't compress better than 12.5% it won't be
> compressed at all. Then in zfs you need extra space for checksums, etc.
>
> How did the OP came up with how much data is being used?
OP, just used `du -sh' at both ends of the transfer. On origin end it
is
Hello Brad,
Monday, March 30, 2009, 7:57:31 PM, you wrote:
BP> I've run into this too... I believe the issue is that the block
BP> size/allocation unit size in ZFS is much larger than the default size
BP> on older filesystems (ufs, ext2, ext3).
BP> The result is that if you have lots of small fi
Right.
Another difference to be aware of is that ZFS reports the total
space consumed, including space for metadata -- typically around 1%.
Traditional filesystems like ufs and ext2 preallocate metadata and
don't count it as using space. I don't know how reiserfs does its
bookkeeping, but I would
I've run into this too... I believe the issue is that the block
size/allocation unit size in ZFS is much larger than the default size
on older filesystems (ufs, ext2, ext3).
The result is that if you have lots of small files smaller than the
block size, they take up more total space on the filesy
I rsynced an 11gb pile of data from a remote linux machine to a zfs
filesystem with compression turned on.
The data appears to have grown in size rather than been compressed.
Many, even most of the files are formats that are already compressed,
such as mpg jpg avi and several others. But also ma
26 matches
Mail list logo
