On Wed, 29 Jul 2009 17:34:53 -0700
Roman V Shaposhnik r...@sun.com wrote:
On the read-write front: wouldn't it be cool to be able to snapshot
things by:
$ mkdir .zfs/snapshot/snap-name
I've followed this thread but I fail to see the advantages of this. I
guess I miss something here. Can
dick hoogendijk wrote:
On Wed, 29 Jul 2009 17:34:53 -0700
Roman V Shaposhnik r...@sun.com wrote:
On the read-write front: wouldn't it be cool to be able to snapshot
things by:
$ mkdir .zfs/snapshot/snap-name
I've followed this thread but I fail to see the
Le 31 juil. 09 à 10:24, dick hoogendijk a écrit :
On Wed, 29 Jul 2009 17:34:53 -0700
Roman V Shaposhnik r...@sun.com wrote:
On the read-write front: wouldn't it be cool to be able to snapshot
things by:
$ mkdir .zfs/snapshot/snap-name
I've followed this thread but I fail to see the
Because it means you can create zfs snapshots from a non solaris/non
local client...
Like a linux nfs client, or a windows cifs client.
T
dick hoogendijk wrote:
On Wed, 29 Jul 2009 17:34:53 -0700
Roman V Shaposhnik r...@sun.com wrote:
On the read-write front: wouldn't it be cool to be
On Fri, 31 Jul 2009 18:38:16 +1000
Tristan Ball tristan.b...@leica-microsystems.com wrote:
Because it means you can create zfs snapshots from a non solaris/non
local client...
Like a linux nfs client, or a windows cifs client.
So if I want a snapshot of i.e. rpool/export/home/dick I can do
dick hoogendijk wrote:
On Fri, 31 Jul 2009 18:38:16 +1000
Tristan Ball tristan.b...@leica-microsystems.com wrote:
Because it means you can create zfs snapshots from a non solaris/non
local client...
Like a linux nfs client, or a windows cifs client.
So if I want a snapshot of i.e.
Roman V Shaposhnik wrote:
On the read-only front: wouldn't it be cool to *not* run zfs sends
explicitly but have:
.zfs/send/snap name
.zfs/sendr/from-snap-name-to-snap-name
give you the same data automagically?
On the read-write front: wouldn't it be cool to be able to snapshot
On Thu, Jul 30, 2009 at 11:33 AM, Darren J
Moffatdarr...@opensolaris.org wrote:
Roman V Shaposhnik wrote:
On the read-only front: wouldn't it be cool to *not* run zfs sends
explicitly but have:
.zfs/send/snap name
.zfs/sendr/from-snap-name-to-snap-name
give you the same data
Cyril Plisko wrote:
On Thu, Jul 30, 2009 at 11:33 AM, Darren J
Moffatdarr...@opensolaris.org wrote:
Roman V Shaposhnik wrote:
On the read-only front: wouldn't it be cool to *not* run zfs sends
explicitly but have:
.zfs/send/snap name
.zfs/sendr/from-snap-name-to-snap-name
give you the
Whoah! Seriously? When did that get added and how did I miss it?
That is absolutely superb! And an even stronger case for mkdir creating
filesystems. A filesystem per user that they can snapshot at will o_0
Ok, it'll need some automated pruning of old snapshots, but even so, that has
Hi Darryn,
On 30/07/2009, at 6:33 PM, Darren J Moffat wrote:
That already works if you have the snapshot delegation as that
user. It even works over NFS and CIFS.
Can you give us an example of how to correctly get this working?
I've read through the manpage but have not managed to get the
James Lever wrote:
Hi Darryn,
On 30/07/2009, at 6:33 PM, Darren J Moffat wrote:
That already works if you have the snapshot delegation as that user.
It even works over NFS and CIFS.
Can you give us an example of how to correctly get this working?
On the host that has the ZFS datasets (ie
On Jul 30, 2009, at 2:15 AM, Cyril Plisko wrote:
On Thu, Jul 30, 2009 at 11:33 AM, Darren J
Moffatdarr...@opensolaris.org wrote:
Roman V Shaposhnik wrote:
On the read-only front: wouldn't it be cool to *not* run zfs sends
explicitly but have:
.zfs/send/snap name
James Lever wrote:
On 30/07/2009, at 11:32 PM, Darren J Moffat wrote:
On the host that has the ZFS datasets (ie the NFS/CIFS server) you
need to give the user the delegation to create snapshots and to mount
them:
# zfs allow -u james snapshot,mount,destroy tank/home/james
Ahh, it was the
What do you think about the following feature?
Subdirectory is automatically a new filesystem property - an administrator
turns
on this magic property of a filesystem, after that every mkdir *in the root* of
that filesystem creates a new filesystem. The new filesystems have
default/inherited
On Wed, 29 Jul 2009, Andriy Gapon wrote:
Subdirectory is automatically a new filesystem property - an administrator
turns
on this magic property of a filesystem, after that every mkdir *in the root* of
that filesystem creates a new filesystem. The new filesystems have
default/inherited
Andriy Gapon wrote:
What do you think about the following feature?
Subdirectory is automatically a new filesystem property - an administrator
turns
on this magic property of a filesystem, after that every mkdir *in the root* of
that filesystem creates a new filesystem. The new filesystems have
On Wed, July 29, 2009 10:24, Andre van Eyssen wrote:
It'd either require major surgery to userland tools, including every
single program that might want to create a directory, or major surgery to
the kernel. The former is unworkable, the latter .. scary.
How about: add a flag (-Z?) to
David Magda wrote:
On Wed, July 29, 2009 10:24, Andre van Eyssen wrote:
It'd either require major surgery to userland tools, including every
single program that might want to create a directory, or major surgery to
the kernel. The former is unworkable, the latter .. scary.
How about: add a
on 29/07/2009 17:24 Andre van Eyssen said the following:
On Wed, 29 Jul 2009, Andriy Gapon wrote:
Subdirectory is automatically a new filesystem property - an
administrator turns
on this magic property of a filesystem, after that every mkdir *in the
root* of
that filesystem creates a new
On Wed, 29 Jul 2009, David Magda wrote:
Which makes me wonder: is there a programmatic way to determine if a path
is on ZFS?
statvfs(2)
--
Andre van Eyssen.
mail: an...@purplecow.org jabber: an...@interact.purplecow.org
purplecow.org: UNIX for the masses http://www2.purplecow.org
On Wed, 29 Jul 2009, David Magda wrote:
Which makes me wonder: is there a programmatic way to determine if a
path is on ZFS?
Yes, if it's local. Just use df -n $path and it'll spit out the filesystem
type. If it's mounted over NFS, it'll just say something like nfs or
autofs, though.
On Wed, 29 Jul 2009, Andriy Gapon wrote:
Well, I specifically stated that this property should not be recursive, i.e. it
should work only in a root of a filesystem.
When setting this property on a filesystem an administrator should carefully set
permissions to make sure that only trusted
On Wed, 29 Jul 2009, Mark J Musante wrote:
Yes, if it's local. Just use df -n $path and it'll spit out the filesystem
type. If it's mounted over NFS, it'll just say something like nfs or autofs,
though.
$ df -n /opt
Filesystemkbytesused avail capacity Mounted on
Andriy Gapon wrote:
What do you think about the following feature?
Subdirectory is automatically a new filesystem property - an administrator
turns
on this magic property of a filesystem, after that every mkdir *in the root* of
that filesystem creates a new filesystem. The new filesystems have
Andre van Eyssen wrote:
On Wed, 29 Jul 2009, Andriy Gapon wrote:
Well, I specifically stated that this property should not be
recursive, i.e. it
should work only in a root of a filesystem.
When setting this property on a filesystem an administrator should
carefully set
permissions to make
Kyle McDonald wrote:
Andriy Gapon wrote:
What do you think about the following feature?
Subdirectory is automatically a new filesystem property - an
administrator turns
on this magic property of a filesystem, after that every mkdir *in the
root* of
that filesystem creates a new filesystem.
On Wed, Jul 29, 2009 at 03:35:06PM +0100, Darren J Moffat wrote:
Andriy Gapon wrote:
What do you think about the following feature?
Subdirectory is automatically a new filesystem property - an
administrator turns
on this magic property of a filesystem, after that every mkdir *in the
Darren J Moffat wrote:
Kyle McDonald wrote:
Andriy Gapon wrote:
What do you think about the following feature?
Subdirectory is automatically a new filesystem property - an
administrator turns
on this magic property of a filesystem, after that every mkdir *in
the root* of
that filesystem
I can think of a different feature where this would be useful - storing virtual
machines.
With an automatic 1fs per folder, each virtual machine would be stored in its
own filesystem, allowing for rapid snapshots, and instant restores of any
machine.
One big limitation for me of zfs is that
On 29.07.09 07:56, Andre van Eyssen wrote:
On Wed, 29 Jul 2009, Mark J Musante wrote:
Yes, if it's local. Just use df -n $path and it'll spit out the
filesystem type. If it's mounted over NFS, it'll just say something
like nfs or autofs, though.
$ df -n /opt
Filesystemkbytes
on 29/07/2009 17:52 Andre van Eyssen said the following:
On Wed, 29 Jul 2009, Andriy Gapon wrote:
Well, I specifically stated that this property should not be
recursive, i.e. it
should work only in a root of a filesystem.
When setting this property on a filesystem an administrator should
On Wed, 2009-07-29 at 15:06 +0300, Andriy Gapon wrote:
What do you think about the following feature?
Subdirectory is automatically a new filesystem property - an administrator
turns
on this magic property of a filesystem, after that every mkdir *in the root*
of
that filesystem creates a
On Wed, Jul 29, 2009 at 05:34:53PM -0700, Roman V Shaposhnik wrote:
On Wed, 2009-07-29 at 15:06 +0300, Andriy Gapon wrote:
What do you think about the following feature?
Subdirectory is automatically a new filesystem property - an
administrator turns
on this magic property of a
Andrew [EMAIL PROTECTED] wrote:
Since ZFS is COW, can I have a read-only pool (on a central file
server, or on a DVD, etc) with a separate block-differential pool on
my local hard disk to store writes?
This way, the pool in use can be read-write, even if the main pool
itself is read-only,
Do an automatic pool snapshot (using the recursive atomic snapshot feature that
Matt Ahrens implemented recently, taking time proportional to the number of
filesystems in the pool) upon every txg commit.
Management of the trashcan snapshots could be done by some user-configurable
policy such
36 matches
Mail list logo