Note that now we have to account for possible partial writes
in dmu_write_uio_dbuf().
It seems that on illumos either all or none of the data are
expected to be written.
But the partial writes are quite expected when vn_io_fault support
is enabled.
Details
- Reviewers
kib - Commits
- rS298105: zfs: enable vn_io_fault support
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
I cannot be an authorative reviewer for the patch, since I do not know ZFS code. Indeed, partial moves must be handled, this is a fundamental principle for the vn_io_fault. On the other hand, I am not quite sure about interaction of the mechanism with ZFS transactions. Is it fine for the single write to be split among several journaled operations ?
That said, the replace of the uiomove() with vn_io_fault_uimove() is all what required for the fs which does not use unmapped cache.
Yes, that's perfectly fine. There is no guarantee that a write is atomic in the event of a system crash or a snapshot being taken or an I/O error, etc.
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c | ||
---|---|---|
1169 ↗ | (On Diff #6135) | @kib as you can see here a write operation already can be split into multiple ZFS transactions and intent log writes. |
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c | ||
---|---|---|
1169–1181 ↗ | (On Diff #6135) | @kib as you can see here a write operation already can be split into multiple ZFS transactions and intent log writes. |