Has any thought been given to exposing some sort of transactional API for ZFS at the user level (even if just consolidation private)? Just recently, it would seem a poorly timed unscheduled poweroff while NWAM was attempting to update nsswitch.conf left me with a 0 byte nsswitch.conf (which when the system came back up, had rather unpleasant results). While not on opensolaris (though I suspect the problem exists there), I''ve also encountered instances where a shutdown while the ldap_client process is in the middle of updating /var/ldap/ldap_client_file has left the file empty. In both instances, additional outages were incurred while things had to be recovered manually. And in both instances, code could be added to each utility to try to recover from such a situation. An easier (and would seem more elegant) solution would be for both utilities to simply be able to mark the ''truncate; write new data'' sequence as atomic, which is possible with zfs. It''s possible other utilities could benefit as well (and would prevent them from all having to implement recovery mechanisms when transitioning data files from one state to another).
For single file updates, this is commonly solved by writing data to a
temp file and using rename(2) to move it in place when it''s ready.
-Norm
On 08/12/10 04:51 PM, Jason wrote:> Has any thought been given to exposing some sort of transactional API
> for ZFS at the user level (even if just consolidation private)?
>
> Just recently, it would seem a poorly timed unscheduled poweroff while
> NWAM was attempting to update nsswitch.conf left me with a 0 byte
> nsswitch.conf (which when the system came back up, had rather
> unpleasant results).
> While not on opensolaris (though I suspect the problem exists there),
> I''ve also encountered instances where a shutdown while the
ldap_client
> process is in the middle of updating /var/ldap/ldap_client_file has
> left the file empty.
> In both instances, additional outages were incurred while things had
> to be recovered manually.
>
> And in both instances, code could be added to each utility to try to
> recover from such a situation. An easier (and would seem more
> elegant) solution would be for both utilities to simply be able to
> mark the ''truncate; write new data'' sequence as atomic,
which is
> possible with zfs. It''s possible other utilities could benefit as
> well (and would prevent them from all having to implement recovery
> mechanisms when transitioning data files from one state to another).
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Thu, Aug 12, 2010 at 07:48:10PM -0500, Norm Jacobs wrote:> For single file updates, this is commonly solved by writing data to > a temp file and using rename(2) to move it in place when it''s ready.For anything more complicated you need... a more complicated approach. Note that "transactional API" means, among other things, "rollback" -- easy at the whole dataset level, hard in more granular form. Dataset- level rollback is nowhere need granular enough for applications). Application transactions consisting of more than one atomic filesystem operation require application-level recovery code. SQLite3 is a good (though maybe extreme?) example of such an application; there are many others. Nico --