[zfs-discuss] User level transactional API
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@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] User level transactional API
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@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] User level transactional API
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 -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
