dick hoogendijk wrote:
On Fri, 31 Jul 2009 18:38:16 +1000
Tristan Ball 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 a
On Fri, 31 Jul 2009 18:38:16 +1000
Tristan Ball 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 a "zfs
snapshot rpool/export/
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 wrote:
On the read-write front: wouldn't it be cool to be able to snapsh
Le 31 juil. 09 à 10:24, dick hoogendijk a écrit :
On Wed, 29 Jul 2009 17:34:53 -0700
Roman V Shaposhnik wrote:
On the read-write front: wouldn't it be cool to be able to snapshot
things by:
$ mkdir .zfs/snapshot/
I've followed this thread but I fail to see the advantages of this. I
gues
dick hoogendijk wrote:
On Wed, 29 Jul 2009 17:34:53 -0700
Roman V Shaposhnik wrote:
On the read-write front: wouldn't it be cool to be able to snapshot
things by:
$ mkdir .zfs/snapshot/
I've followed this thread but I fail to see the advantages of this. I
guess I m
On Wed, 29 Jul 2009 17:34:53 -0700
Roman V Shaposhnik wrote:
> On the read-write front: wouldn't it be cool to be able to snapshot
> things by:
> $ mkdir .zfs/snapshot/
I've followed this thread but I fail to see the advantages of this. I
guess I miss something here. Can you explain to me wh
On Thu, 2009-07-30 at 09:33 +0100, Darren J Moffat 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/
> > .zfs/sendr/-
> > give you the same data automagically?
> >
> > On the read-write front:
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
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 lack of mount that
On Jul 30, 2009, at 2:15 AM, Cyril Plisko wrote:
On Thu, Jul 30, 2009 at 11:33 AM, Darren J
Moffat 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/
.zfs/sendr/-
give you the same data automagically?
On th
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
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
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
so
Cyril Plisko wrote:
On Thu, Jul 30, 2009 at 11:33 AM, Darren J
Moffat 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/
.zfs/sendr/-
give you the same data automagically?
On the read-write front: wouldn't it
On Thu, Jul 30, 2009 at 11:33 AM, Darren J
Moffat 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/
>> .zfs/sendr/-
>> give you the same data automagically?
>> On the read-write front: wouldn't it
Roman V Shaposhnik wrote:
On the read-only front: wouldn't it be cool to *not* run zfs sends
explicitly but have:
.zfs/send/
.zfs/sendr/-
give you the same data automagically?
On the read-write front: wouldn't it be cool to be able to snapshot
things by:
$ mkdir .zfs/snapshot/
T
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
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 c
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
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
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 al
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 c
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 *i
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.
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 sur
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 hav
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
/dev/md/d
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 entitie
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.
Reg
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
pur
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 cr
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 fl
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 use
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 hav
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 proper
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 p
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, with
On Tue, Jul 25, 2006 at 11:02:14PM -0700, Andrew 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 p
On Tue, Jul 25, 2006 at 11:23:21PM -0700, Andrew wrote:
> 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.
This is a good idea, one that
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 as
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, without having to make a full local co
41 matches
Mail list logo
