Re: Journals and jscan

["Steve O'Hara-Smith" <steve@xxxxxxxxxx>]

	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).

On Tue, 16 Jan 2007 10:37:29 -0800 (PST)
Matthew Dillon <dillon@apollo.backplane.com> wrote:

> :> 	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 :)

>  A second issue is that a frontend has to
> be written to reconnect and restart the journaling stream when the
>     connection is lost and to deal long term connection failures (i.e. if
>     one of the boxes is brought down).

	OK that I already have solved :). I had in mind spooling
journals to a local store, then using a frequent cron job to transfer them
using jscan | ssh jscan and finally a cron job on the remote end to update
the mirror from jscan. I think this scheme takes care of the restarts and
connection issues reasonably well - the cron jobs will need holdoffs
against multiple runs and probably a disabling flag file would be handy.

> :Bad path: /vi.recover/vi.fH1xrt
> :Bad path: /vi.recover/vi.fH1xrt
> :Bad path: /vi.recover/vi.fH1xrt
> 
>     Hmm.  The path shouldn't be absolute.  Try using the -D option to 
>     jscan to specify the base directory for mirroring operations.
> 
>     ... | 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.

-- 
C:>WIN                                      |   Directable Mirror Arrays
The computer obeys and wins.                | A better way to focus the sun
You lose and Bill collects.                 |    licences available see
                                            |    http://www.sohara.org/