I keep thinking that it would be useful to be able to define a zfs file system where all calls to mkdir resulted not just in a directory but in a file system. Clearly such a property would not be inherited but in a number of situations here it would be a really useful feature. I can see there would be issues with access these new file systems over NFS as NFS is currently not to good when new file systems are created, but has any one considered this? This message posted from opensolaris.org
> I keep thinking that it would be useful to be able to define a zfs file system where all calls to mkdir resulted not just in a directory but in a file system. Clearly such a property would not be inherited but in a number of situations here it would be a really useful feature.Any example use cases? :) -- Regards, Jeremy
Jeremy Teo wrote:>> I keep thinking that it would be useful to be able to define a zfs >> file system where all calls to mkdir resulted not just in a directory >> but in a file system. Clearly such a property would not be inherited >> but in a number of situations here it would be a really useful feature. > > Any example use cases? :)Taking into account that Chris said this would NOT be inherited by default. Any mkdir in a builds directory on a shared build machine. Would be very cool because then every user/project automatically gets a ZFS fileystems. Why map it to mkdir rather than using zfs create ? Because mkdir means it will work over NFS or CIFS. -- Darren J Moffat
Jeremy Teo wrote:>> I keep thinking that it would be useful to be able to define a zfs >> file system where all calls to mkdir resulted not just in a directory >> but in a file system. Clearly such a property would not be inherited >> but in a number of situations here it would be a really useful feature. > > Any example use cases? :)Keeping data associated with a customer case. Currently we do this in a number of file systems and then fake them up using symlinks to look like a flat directory as a single file system is not big enough. It would be really cool to use ZFS so that there was just one file system. However it would be even cooler if each directory in that pool was a file system. So there is a file system per customer case, without having to do rbac thing to have the file systems created. Then we could easily see where the space was and could archive file systems rather than directories plus snapshot based on activity in the case. -- Chris Gerhard. __o __o __o Sun Microsystems Limited _`\<,`\<,`\<,_ Phone: +44 (0) 1252 426033 (ext 26033) (*)/---/---/ (*) ----------------------------------------------------------- http://blogs.sun.com/chrisg ----------------------------------------------------------- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20060928/8de636e6/attachment.bin>
>Any mkdir in a builds directory on a shared build machine. Would be >very cool because then every user/project automatically gets a ZFS >fileystems. > >Why map it to mkdir rather than using zfs create ? Because mkdir means >it will work over NFS or CIFS."NFS" will be fairly difficult because you will then have a filesystem you cannot reach. (You can''t traverse file systems that easily at the moment over NFS) CIFS just requires the automount hack. (And if you don''t need it to work remotely automount could take care of it if you think "cd" should be sufficient reason to create a directory) Casper
On Thu, Sep 28, 2006 at 05:29:27PM +0200, Casper.Dik at Sun.COM wrote:> > >Any mkdir in a builds directory on a shared build machine. Would be > >very cool because then every user/project automatically gets a ZFS > >fileystems. > > > >Why map it to mkdir rather than using zfs create ? Because mkdir means > >it will work over NFS or CIFS. > > "NFS" will be fairly difficult because you will then have a filesystem > you cannot reach. (You can''t traverse file systems that easily at the > moment over NFS) CIFS just requires the automount hack.For v4 the fix is coming though.> (And if you don''t need it to work remotely automount could take care of it > if you think "cd" should be sufficient reason to create a directory)Maybe on unmount empty filesystems could be destroyed.
Hello Chris,
Thursday, September 28, 2006, 4:55:13 PM, you wrote:
CG> I keep thinking that it would be useful to be able to define a
CG> zfs file system where all calls to mkdir resulted not just in a
CG> directory but in a file system. Clearly such a property would not
CG> be inherited but in a number of situations here it would be a really
useful feature.
CG> I can see there would be issues with access these new file
CG> systems over NFS as NFS is currently not to good when new file
CG> systems are created, but has any one considered this?
CG>
dtrace -w -n syscall::mkdir:entry''{system("zfs create %s\n",
copyinstr(arg0+1));}''
Should do the job :)
ps. just kidding - but it will work to some extent :)
--
Best regards,
Robert mailto:rmilkowski at task.gda.pl
http://milek.blogspot.com
> > (And if you don''t need it to work remotely automount could take care of it > > if you think "cd" should be sufficient reason to create a directory) > > Maybe on unmount empty filesystems could be destroyed.more general? If we have "events" like a library-call to "mkdir" or "change-dir" or "no open filedescriptors" or ?nmount", then operator-predefined actions will be triggered. Actions like "zfs create <rulebased-name>", "take a snapshot" or "zsend on a snapshot" and others could be thought of. Thomas --
Please elaborate: "CIFS just requires the automount hack." Ron This message posted from opensolaris.org
On Thu, Sep 28, 2006 at 09:00:47AM -0700, Ron Halstead wrote:> Please elaborate: "CIFS just requires the automount hack."Samba''s smb.conf supports a "root preexec" parameter that allows a program to be run when a share is connected to. For example, with a simple script, createhome.sh, like, #!/usr/bin/bash if [ ! -e /tank/home/$1 ]; then zfs create tank/home/$1 fi and a [homes] share in smb.conf like, [homes] comment = User Home Directories browseable = no writable = yes root preexec = createhome.sh ''%U'' Samba will automatically create a ZFS filesystem for each user''s home directory the first time the user connects to the server. You''d likely want to expand on this to have it properly set the permissions, perform some additional checks and logging, etc. This can be elaborated on to do neat things like create a ZFS clone when a client connects and then destroy the clone when the client disconnects (via "root postexec"). This could possibly be useful for the shared build system that was mentioned by an earlier post. To truely replace every mkdir call you can write a fairly simple VFS module for Samba that would replace every mkdir call with a call to "zfs create". This method is a bit more involved than the above method since the VFS modules are coded in C, but it''s definitely a possibility. Ed Plese
This works like a champ: smbclient -U foobar \\\\samba_server\\home Given a UNIX account foobar with a smbpasswd for the account, the zfs filesystem pool/home/foobar was created and smclient connected to it. Thank you. Ron Halstead This message posted from opensolaris.org
On Thu, Sep 28, 2006 at 12:40:17PM -0500, Ed Plese wrote:> This can be elaborated on to do neat things like create a ZFS clone when > a client connects and then destroy the clone when the client > disconnects (via "root postexec"). This could possibly be useful for > the shared build system that was mentioned by an earlier post.To follow up on this, here''s an example share from smb.conf that accomplishes this: [build] comment = Build Share writable = yes path = /tank/clones/%d root preexec = zfs clone tank/clones/base at snap tank/clones/%d root postexec = zfs destroy tank/clones/%d This gives you a fresh clone every time you connect to the share. Ed Plese
>Please elaborate: "CIFS just requires the automount hack."CIFS currently access the files through the local file system so it can invoke the automouter and there can use "tricky maps". Casper
On Fri, Sep 29, 2006 at 01:26:04AM +0200, Casper.Dik at Sun.COM wrote:> > >Please elaborate: "CIFS just requires the automount hack." > > > CIFS currently access the files through the local file system so > it can invoke the automouter and there can use "tricky maps".Well, Samba does. And it doesn''t even need the automounter :)
On Thu, Sep 28, 2006 at 05:36:16PM +0200, Robert Milkowski wrote:> Hello Chris, > > Thursday, September 28, 2006, 4:55:13 PM, you wrote: > > CG> I keep thinking that it would be useful to be able to define a > CG> zfs file system where all calls to mkdir resulted not just in a > CG> directory but in a file system. Clearly such a property would not > CG> be inherited but in a number of situations here it would be a really useful feature. > > CG> I can see there would be issues with access these new file > CG> systems over NFS as NFS is currently not to good when new file > CG> systems are created, but has any one considered this? > CG> > > > dtrace -w -n syscall::mkdir:entry''{system("zfs create %s\n", copyinstr(arg0+1));}'' > > Should do the job :) > > > ps. just kidding - but it will work to some extent :)You''d have to stop() the victim and prun it after the mkdir. And you''d have to use predicates to do this only for the mkdirs of interest. And you''d have to be willing to deal with drops (where the mkdir just doesn''t happen). Nico --
> Why map it to mkdir rather than using zfs create ? Because mkdir means > it will work over NFS or CIFS.Also your users and applications don''t need to know. The administrator sets the policy and then it just happens, plus the resulting "directories" would end up with the correct ownership mode etc. To be complete I suppose there should be the option to have rmdir == zfs destroy as well in that file system. This message posted from opensolaris.org