Hey, I discovered a bug a while ago. If you have a zvol set sharenfs, and you do a rollback on the filesystem, it fails (as it should) because the filesystem is in use. However, the zvol is un-shared from NFS as one of the first steps of rollback, and it''s not turned back on when the procedure is aborted. I submitted a bug & put my name on request_sponsor but I guess that was ignored / lost / deleted attached is the patch file I generated, it patches against b60... In case anyone wants it. Integration would be nice too. -- This messages posted from opensolaris.org -------------- next part -------------- A non-text attachment was scrubbed... Name: zfs-rollback-bug-fix.diff.bz2 Type: application/x-bzip2 Size: 43428 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-code/attachments/20070421/cb159a6b/attachment.bin>
Forgot, my opensolaris contributor ID is OS0051 -- This messages posted from opensolaris.org
On Apr 21, 2007, at 3:42 PM, John Sonnenschein wrote:> Hey, I discovered a bug a while ago. If you have a zvol set > sharenfs, and you do a rollback on the filesystem, it fails (as it > should) because the filesystem is in use. > > However, the zvol is un-shared from NFS as one of the first steps > of rollback, and it''s not turned back on when the procedure is > aborted. > > I submitted a bug & put my name on request_sponsor but I guess > that was ignored / lost / deleted > > attached is the patch file I generated, it patches against b60... > In case anyone wants it. Integration would be nice too.Agreed. That bug (or at least a similar on) is: 6537472 If zfs unmount fails it leaves the file system unshared. let me see about getting those changes in... eric