[zfs-discuss] Re: Re: Re: Re: Re: ZFS consistency guarantee
I wish there was a uniform way whereby applications could register their ability to achieve or release consistency on demand, and if registered, could also communicate back that they had either achieved consistency on-disk, or were unable to do so. That would allow backup procedures to automatically talk to apps capable of such functions, to get them to a known state on-disk before taking a snapshot. That would allow one to for example not stop a DBMS, but simply have it seem to pause for a moment while achieving consistency and until told that the snapshot was complete; thus providing minimum impact while still having fully usable backups (and without needing to do the database backups _through_ the DBMS). Something I heard once leads me to believe that some such facility or convention for how to communicate such issues with e.g. database server processes exists on Windows. If they've got it, we really ought to have something even better, right? :-) (That's of course not specific to ZFS, but would be useful with any filesystem that can take snapshots.) This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re: Re: Re: Re: ZFS consistency guarantee
On Jun 9, 2007, at 06:14, Richard L. Hamilton wrote: I wish there was a uniform way whereby applications could register their ability to achieve or release consistency on demand, and if registered, could also communicate back that they had either achieved consistency on-disk, or were unable to do so. This doesn't (necessarily) have to be built into the kernel: a user space program could work as (say like D-Bus). Any interested program can register / listen for updates (read-only), and anytime a backup program is about to run it can send out an event saying that the /foo/bar directory tree (and below) will be backed up (or snapshotted (word?)). If you have /var/run/backups| where the user ownership is the backup program's user (or using a SUID program to send notifications), an the group is read-only (640), process owners (like oracle, mysql, postgres, etc.) are members of that read-only group so that they can't affect other programs by sending spurious messages. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
