Re: Hammer: Transactional file updates

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hi,
:
:So Hammer does not guarantee "transctional consistency" of data in case
:of a crash, only that of meta-data, right?
:
:Is there a method to guarantee the write to be transactional, so that
:I either have the previous "version" of the file or the version that I
:wrote? Like this:
:
:   fd = open(file);  // behaves like START TRANSACTION
:   read(fd, ...);
:   write(fd, ...);
:   close(fd);        // behaves like COMMIT
:
:That would be incredible cool (and very useful!) and could play well due
:to Hammers historical nature.
:
:I know I could probably solve this issue by creating a new file,
:fsyncing it and then doing a "rm old_file; mv new_file old_file" (or
:something like that), but that would give me a new inode number, which
:I'd like to avoid.
:
:Regards,
:
:   Michael

    Well, you will never see garbage in the data, but there is no
    integrated API available for enclosing multiple operations in a
    single transaction.

    If you do a sequence of write()'s and nothing else the blocks will be
    committed to the media at the operating system's whim, meaning not
    necessarily in order, so a crash would result in spotty updates of the
    file's data.  You will never get garbage like you can with UFS, but it
    is not an all-or-nothing situation either.

    --

    Can an arbitrary transactional API be implemented in HAMMER?  Yes, it
    can.  This is how you do it:

    * run 'hammer synctid' to get a snapshot transction id, write the TID
      to a file somewhere.  fsync().

    * issue the operations you want to be atomic

    * run 'hammer synctid' to get a snapshot transction id, write the TID
      to a file somewhere.  fsync().

    If a crash occurs during the sequence you can do a selective rollback
    to the recorded TID for the portion of the filesystem you modified.
    It could be done now, in fact, by using something like:

	# perform rollback
	cpdup -V directory@@<snapshot> directory

    But it wouldn't be very efficient if the directory contained large
    files needing rollbacks.  To do it right I would need to implement
    an ioctl() to perform the rollback in-place.  The HAMMER VFS already
    has whole-filesystem rollback code... it is used when upgrading a
    PFS slave to a PFS master to get rid of any partially synced data.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>