On 02/19/11 01:00 PM, Rahul Deb wrote:
Hi All,
I have two text files:
1. *snap_prev.txt:* This one lists the name of the immediate previous
snapshots of the 100 zfs file systems. One per line.
2. *snap_latest.txt:* This one contains the name of the corresponding
latest snapshots of those 1
Sorry, I forgot to mention. This is for Incremental Snapshots
On Fri, Feb 18, 2011 at 4:00 PM, Rahul Deb wrote:
> Hi All,
>
> I have two text files:
>
> 1. *snap_prev.txt:* This one lists the name of the immediate previous
> snapshots of the 100 zfs file systems. One per line.
>
> 2. *snap_lates
Hi All,
I have two text files:
1. *snap_prev.txt:* This one lists the name of the immediate previous
snapshots of the 100 zfs file systems. One per line.
2. *snap_latest.txt:* This one contains the name of the corresponding latest
snapshots of those 100 zfs file systems. One per line.
Is it pos
Here is part of what could be the answer:
https://launchpad.net/~dajhorn/+archive/zfs
A DKMS solution implemented using zfsonlinux.org and kqstor.com. I don't
know how this is related to the Pinguy version, but suspect this is a
DKMS'ization
of what they did. Will let you know when I find out...
One of my old pools was version 10, another was version 13.
I guess that explains the problem.
Seems like time-sliderd should refuse to run on pools that
aren't of a sufficient version.
Cindy Swearingen wrote on 02/18/11 12:07 PM:
Hi Bill,
I think the root cause of this problem is that time s
Hi Bill,
I think the root cause of this problem is that time slider implemented
the zfs destroy -d feature but this feature is only available in later
pool versions. This means that the routine removal of time slider
generated snapshots fails on older pool versions.
The zfs destroy -d feature
In the last few days my performance has gone to hell. I'm running:
# uname -a
SunOS nissan 5.11 snv_150 i86pc i386 i86pc
(I'll upgrade as soon as the desktop hang bug is fixed.)
The performance problems seem to be due to excessive I/O on the main
disk/pool.
The only things I've changed recent
On 17/02/2011 20:44, Stefan Dormayer wrote:
is there a way to disable the subcommand destroy of zpool/zfs for the
root user?
ZFS doesn't actually require root for those it actually checks for
individual privileges. Mostly that amounts to "sys_mount" and
"sys_config" (for pool operations) - t