Re: [zfs-discuss] missing features?Could/should zfs support a new ioctl, constrained if neede
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@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] missing features?Could/should zfs support a new ioctl, constrained if neede
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
