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 <[EMAIL PROTECTED]> 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/