zfs discuss - Mar 2007 - missing features?Could/should zfs support a new ioctl, constrained if neede

_FIOSATIME - why doesn''t zfs support this (assuming I didn''t
just miss it)?
Might be handy for backups.

Could/should zfs support a new ioctl, constrained if needed to files of
zero size, that sets an explicit (and fixed) blocksize for a particular
file?  That might be useful for performance in special cases when one
didn''t necessarily want to specify (or depend on the specification of
perhaps) the attribute at the filesystem level.  One could imagine a
database that was itself tunable per-file to a similar range of
blocksizes, which would almost certainly benefit if it used those sizes
for the corresponding files.  Additional capabilities that might be
desirable: setting the blocksize to zero to let the system return to
default behavior for a file; being able to discover the file''s
blocksize
(does fstat() report this?) as well as whether it was fixed at the
filesystem level, at the file level, or in default state.

Wasn''t there some work going on to add real per-user (and maybe
per-group)
quotas, so one doesn''t necessarily need to be sharing or automounting
thousands of individual filesystems (slow)?  Haven''t heard anything
lately though...
 
 
This message posted from opensolaris.org

Richard L. Hamilton writes:
 > _FIOSATIME - why doesn''t zfs support this (assuming I
didn''t just miss it)?
 > Might be handy for backups.
 > 

Are these syscall sufficent ?

     int utimes(const char *path, const struct timeval times[2]);
     int futimesat(int fildes, const char *path, const struct timeval times[2]);

 > Could/should zfs support a new ioctl, constrained if needed to files of
 > zero size, that sets an explicit (and fixed) blocksize for a particular
 > file?  That might be useful for performance in special cases when one
 > didn''t necessarily want to specify (or depend on the
specification of
 > perhaps) the attribute at the filesystem level.  One could imagine a
 > database that was itself tunable per-file to a similar range of
 > blocksizes, which would almost certainly benefit if it used those sizes
 > for the corresponding files.  Additional capabilities that might be
 > desirable: setting the blocksize to zero to let the system return to
 > default behavior for a file; being able to discover the file''s
blocksize
 > (does fstat() report this?) as well as whether it was fixed at the
 > filesystem level, at the file level, or in default state.
 > 

Yep, It does look interesting. 


 > Wasn''t there some work going on to add real per-user (and maybe
per-group)
 > quotas, so one doesn''t necessarily need to be sharing or
automounting
 > thousands of individual filesystems (slow)?  Haven''t heard
anything lately though...
 >  

What is slow here is mounting all those FS at boot and
unmounting at shutdown. The most relevant project here in my 
mind is :

	6478980 zfs should support automount property

which would give ZFS a mount on demand behavior. Fast boot/shutdown
and fewer mounted FS at any one time.

Then we need to make administrating many user FS as painless as
administring a single one.

-r

 >  
 > This message posted from opensolaris.org
 > _______________________________________________
 > zfs-discuss mailing list
 > zfs-discuss at opensolaris.org
 > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

>What is slow here is mounting all those FS at boot and
>unmounting at shutdown. The most relevant project here in my 
>mind is :
>
>	6478980 zfs should support automount property
>
>which would give ZFS a mount on demand behavior. Fast boot/shutdown
>and fewer mounted FS at any one time.

Tricky bit there might be the "mount & share on demand" for NFS
shares.

Casper

Richard L. Hamilton writes:
> _FIOSATIME - why doesn''t zfs support this (assuming I
didn''t just miss it)?
> Might be handy for backups.
Roch Bourbonnais writes:
> Are these syscall sufficent ?
> int utimes(const char *path, const struct timeval times[2]);
> int futimesat(int fildes, const char *path, const struct timeval times[2]);
No, the difference is that utimes() and futimesat() also update ctime, while the
_FIOSATIME ioctl only changes the atime (requires privilege).  This allows
backup software or file scanning software to save and restore the original atime
after processing, where changing the ctime is undesirable.   Unfortunately,
according to the Solaris source browser, the _FIOSATIME ioctl is only
implemented for ufs, not for zfs.

For example, we use a locally-written file scanner to detect changes to file
checksums, and would like to preserve atime and ctime.  I was very happy to
discover the _FIOSATIME ioctl, even though it is not an officially supported
interface.  Also, "star" backup software uses this capability. 
Assuming _FIOSATIME continues to work on ufs, it would make sense to implement
on zfs and other filesystems for consistency.

I see there is a separate thread on implementing O_NOATIME for open() or
fcntl(), which would be compatible with Linux (and would avoid updating the
atime at all, rather than updating it twice).
http://www.opensolaris.org/jive/thread.jspa?messageID=195813
This presumably would also require support from the filesystem.

I assume that an existing _FIOSATIME ioctl could be implemented for zfs and
available sooner than a new O_NOATIME flag for open/fcntl, although uniform
support for O_NOATIME makes more sense in the long run, especially for
cross-platform compatibility.
 
 
This message posted from opensolaris.org