On Sat, Dec 19, 2009 at 05:25, Ian Collins i...@ianshome.com wrote:
Stacy Maydew wrote:
The commands zpool list and zpool get dedup pool both show a ratio
of 1.10.
So thanks for that answer. I'm a bit confused though if the dedup is
applied per zfs filesystem, not zpool, why can I only see
devzero: when you have an exported pool with no log disk and you want to mount
the pool.
Here is the changes to make it compile on dev-129:
--- logfix.c.2009-04-26 2009-12-18 11:39:40.917435361 -0800
+++ logfix.c2009-12-18 12:19:27.507337246 -0800
@@ -20,6 +20,7 @@
#include stddef.h
Hi;
After some very hairy testing, I came up with the following procedure
for sending a zfs send datastream to a gzip staging file and later
"receiving" it back to the same filesystem in the same pool.
The above was to enable the filesystem data to be dedup.
However, after the final ZFS
Written by jktorn:
Have you tried build 128 which includes pool recovery support?
This is because FreeBSD hostname (and hostid?) is recorded in the
labels along with active pool state.
It does not work that way at the moment, though readonly import is
quite useful option that can be tried.
Yes,
I have a system that was recently upgraded to Solaris 10 10/09. It
has a UFS root on local disk and a separate zpool on Iscsi disk.
After a reboot, the ZFS filesystems were not mounted, although the
zpool had been imported. `zfs mount' showed nothing. `zfs mount -a'
mounted them nicely. The
On Sat, 19 Dec 2009, Colin Raven wrote:
There is no original, there is no copy. There is one block with reference
counters.
- Fred can rm his file (because clearly it isn't a file, it's a filename and
that's all)
- result: the reference count is decremented by one - the data remains on disk.
On Sat, Dec 19, 2009 at 17:20, Bob Friesenhahn bfrie...@simple.dallas.tx.us
wrote:
On Sat, 19 Dec 2009, Colin Raven wrote:
There is no original, there is no copy. There is one block with reference
counters.
- Fred can rm his file (because clearly it isn't a file, it's a filename
and
On Sat, 19 Dec 2009, Colin Raven wrote:
Wait...whoah, hold on.
If snapshots reside within the confines of the pool, are you saying that dedup
will also count
what's contained inside the snapshots? I'm not sure why, but that thought is
vaguely disturbing on
some level.
Yes, of course. Any
On Sat, Dec 19, 2009 at 7:20 PM, Bob Friesenhahn
bfrie...@simple.dallas.tx.us wrote:
On Sat, 19 Dec 2009, Colin Raven wrote:
There is no original, there is no copy. There is one block with reference
counters.
- Fred can rm his file (because clearly it isn't a file, it's a filename
and
On 19-Dec-09, at 4:35 AM, Colin Raven wrote:
...
There is no original, there is no copy. There is one block with
reference counters.
Many blocks, potentially shared, make up a de-dup'd file. Not sure
why you write one here.
- Fred can rm his file (because clearly it isn't a file,
On 19-Dec-09, at 11:34 AM, Colin Raven wrote:
...
Wait...whoah, hold on.
If snapshots reside within the confines of the pool, are you saying
that dedup will also count what's contained inside the snapshots?
Snapshots themselves are only references, so yes.
I'm not sure why, but that
On Sat, Dec 19, 2009 at 19:08, Toby Thain t...@telegraphics.com.au wrote:
On 19-Dec-09, at 11:34 AM, Colin Raven wrote
Then again (not sure how gurus feel on this point) but I have this probably
naive and foolish belief that snapshots (mostly) oughtta reside on a
separate physical
On 19-Dec-09, at 2:01 PM, Colin Raven wrote:
On Sat, Dec 19, 2009 at 19:08, Toby Thain
t...@telegraphics.com.au wrote:
On 19-Dec-09, at 11:34 AM, Colin Raven wrote
Then again (not sure how gurus feel on this point) but I have this
probably naive and foolish belief that snapshots
On 19-Dec-09, at 11:34 AM, Colin Raven wrote:
...
When we are children, we are told that sharing is good. In the
case or references, sharing is usually good, but if there is a huge
amount of sharing, then it can take longer to delete a set of files
since the mutual references create a
14 matches
Mail list logo
