On Sat, Aug 28, 2010 at 12:05:53PM +1200, Ian Collins wrote: > Think of this from the perspective of an application. How would > write failure be reported? open(2) returns EACCES if the file can > not be written but there isn't a corresponding return from write(2). > Any open file descriptors would have to be updated to reflect the > change of access and the application would end up with an unexpected > error return (EBADF?).
EROFS. But write(2) isn't supposed to return EROFS. NFSv3's and v4's write ops are allowed to return the NFS equivalent of EROFS, and so typically NFS clients do cause write(2) to return EROFS in such cases (but then, NFS isn't fully POSIX). write(2) can return EIO though, and, IIRC, the BSD revoke(2) syscall arranges for just that to be returned by write(2) calls on revoked fildes. IMO EROFS and EIO would both be OK. It might be a good idea to require a force option to make a change that would cause non-POSIX behavior. I'd think that there's many possible ways to handle this: a) disallow setting readonly=on on mounted datasets that are readonly=false; b) disallow ... but only if there are any fildes open for write (doesn't matter if shared with NFS as NFS writes are allowed to return EROFS); c) allow the change but make it take effect on next mount; d) force umount the dataset, make the change, mount again; e) have write(2), to fildes open for write before the change to readonly=on, return EROFS after the change; f) same as (d) but only if you force the prop change; g) have write(2), to fildes open for write before the change to readonly=on, return EIO after the change; h) allow write(2)s to fildes open for write before the change to readonly=on; (h) is current behavior. (a) and (b) would be reasonable, but if EBUSY, the user may not be able to change the property without drastic steps (such as rebooting, if there's lots of datasets below). (c) would be confusing, and not that useful. (d) would be unreasonable (plus what if there's datasets below this one?!). (e)... may be reasonable if you think that we're well outside POSIX the moment you change the readonly prop to on. (f) is reasonable (by forcing the change you'd be saying that you're happy to leave POSIX land). (h) is reasonable. > If the application has been given permission to open a file for > writing and this permission is unexpectedly revoked, strange things > my happen. The file being written would be in an inconsistent > state. Well, there's always the BSD revoke(2) system call. Use it and > I think it is better to let write operation complete and leave the > file in a consistent state. There is that too. But you could, too, just power off... The application should use fsync(2) (or fdatasync()) carefully to ensure that failed write(2)s and power failures don't leave the application in an unrecoverable state. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
