Matthew Ahrens wrote:
Manoj Joseph wrote:
Hi,
I find that fchmod(2) on a zfs filesystem can sometimes generate errno
= ENOSPC. However this error value is not in the manpage of fchmod(2).
Here's where ENOSPC is generated.
zfs`dsl_dir_tempreserve_impl
zfs`dsl_dir_tempreserve_space+0x4e
zfs`dmu_tx_try_assign+0x230
zfs`dmu_tx_assign+0x21
zfs`zfs_setattr+0x41b
genunix`fop_setattr+0x24
genunix`vpsetattr+0x110
genunix`fdsetattr+0x26
genunix`fchmod+0x2a
genunix`dtrace_systrace_syscall+0xbc
unix`sys_sysenter+0x101
Is this correct behavior? Is it the manpage that needs fixing? zpool
list shows this.
In a COW filesystem such as ZFS, it will sometimes be necessary to
return ENOSPC in cases such as chmod(2) which previously did not. This
is because there could be a snapshot, so "overwriting" some information
actually requires a net increase in space used.
Could the manpage be updated to reflect this?
That said, we may be generating this ENOSPC in cases where it is not
strictly necessary (eg, when there are no snapshots). We're working on
some of these cases. Can you show us the output of 'zfs list' when the
ENOSPC occurs?
-bash-3.00# zfs list pool1
NAME USED AVAIL REFER MOUNTPOINT
pool1 83.0M 0 82.8M /pool1
-bash-3.00# zpool list pool1
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
pool1 115M 83.0M 32.0M 72% ONLINE -
zfs list does say that there is no available space. There is 32M
available on the zpool though. Interesting...
Regards,
Manoj
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
