Re: Journals and jscan

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:	Hi,
:
:	I could have sworn I replied to this already - looks like I lost
:it, probably when I realised that I had locked up my /tmp playing with
:jscan and mountctl (methinks that ^C on a mountctl | jscan command is
:probably a bad idea).

     Now that virtual kernels are working you can play with that stuff
     inside a virtual kernel.

:> :> 	I have at last got two DragonFly boxes up and it seems like a
:> good :> idea to get some data security with jscan based mirrors.
:> 
:>     I don't think it's production ready for that sort of thing.  The main
:>     problem is that the link represents a choke point and reduces
:> filesystem performance greatly.
:
:	That's probably OK for me, presumably it is only write performance
:that suffers (I can always use noatime mounts to minimise writing). The
:filesystems I have in mind for this are not ones that see  performance
:critical writes (the ones that do are ones I don't want to mirror like
:this). Also my current strategy involves hourly rsync runs which not only
:reduce the performance of the filesystem being backed up but also
:everything else on the disc, so I may be better off for performance where
:it matters :)

    Primarily write performance, yes, but there is a second issue as well
    and that is the fact that every single write is recorded in the journal
    as a separate event.  This can be a problem because many programs make
    temporary changes to files or to piecemeal updates to the same file.

    With a snapshot a modified file block is replicated only once after the
    snapshot is taken.  All further updates to that file block simply rewrite
    the new version of it until the next snapshot is taken.  This yields much
    higher performance at the cost of not having an infinite-fine-grained
    journal.

    Because of this I don't think the journal is suitable for all situations.


:...
:>     ... | jscan -m stdin -D /home/hournal_test/tmp
:
:	That (and variations on the theme) all produce the same Bad path:
:messages and paths with leading /s appear in the jscan -d output too. The
:paths aren't really absolute they are relative to the mount point but have
:a leading / and so look absolute.
:
:	I'm using a very up to date Preview build BTW.

    Since journaling is still highly experimental I am not going to worry
    about it for this release, but please remind me after the release and
    I will look into the bad path problem.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>