Re: Journals and jscan
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/
Re: When will 1.8 be branched?
Steve O'Hara-Smith wrote: On Mon, 22 Jan 2007 20:44:48 +1100 Petr Janda <[EMAIL PROTECTED]> wrote: I think you are being slightly absurd. If you want DragonFly to go into businesses/corporations you have to be prepared they *have* demands , Nobody has any business making demands of volunteers. and they are much bigger than mine "is it gonna be branched today as planned", Personally I would much rather see branching and releases happening when the developers feel it is ready to happen than on a planned date. That being said the DragonFLy team seems to do better at hitting the planned dates than most commercial OS developments. I don't make the demands but I am demanded by my clients to satisfy them by supplying them a good product. If it was entirely up to me I wouldnt be making the inquiries at all(I dont care if its released in january or 3 months later) but I have clients, hence why Ive often turned to FreeBSD when DF was missing a feature which I needed. Therefore I might be sounding to have demanding tone, but thats because DF is my personal OS of choice and especially because of my clients. (not that they specifically request DF but because thats what I offer them + maintenance). My apologies. Petr
Re: When will 1.8 be branched?
--- Petr Janda <[EMAIL PROTECTED]> escribió: > Steve O'Hara-Smith wrote: > > On Mon, 22 Jan 2007 20:44:48 +1100 > > Petr Janda <[EMAIL PROTECTED]> wrote: > > > > > >> I think you are being slightly absurd. If you > want DragonFly to go into > >> businesses/corporations you have to be prepared > they *have* demands , > >> > > > > Nobody has any business making demands of > volunteers. > > > > > >> and they are much bigger than mine "is it gonna > be branched today as > >> planned", > >> > > > > Personally I would much rather see branching and > releases happening > > when the developers feel it is ready to happen > than on a planned date. > > > > That being said the DragonFLy team seems to do > better at hitting > > the planned dates than most commercial OS > developments. > > > > > I don't make the demands but I am demanded by my > clients to satisfy them > by supplying them a good product. If it was entirely > up to me I wouldnt > be making the inquiries at all(I dont care if its > released in january or > 3 months later) but I have clients, hence why Ive > often turned to > FreeBSD when DF was missing a feature which I > needed. Therefore I might > be sounding to have demanding tone, but thats > because DF is my personal > OS of choice and especially because of my clients. > (not that they > specifically request DF but because thats what I > offer them + maintenance). > > My apologies. > > Petr > I'm an early newbie and not having clue about development but... Have you considered to pay developers for having those exact branching dates and features you want for your clients? If you receive something for free, I think you can't demand something. If you pay explicitely for it (and I don't mean just donations), then you can. As I've seen as in my stupid user experience on other projects, it's better to not give dates when you are unsure to comply them. Then is better to give approximately dates thinking in the worst situation, so if it's released earlier it will look like a nice surprise ;) __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com
Re: When will 1.8 be branched?
I am branching the tree today. But, guys, the release date hasn't change. Branch != release. I pushed back the release date to late January in December and haven't puished it back a second time. The only thing that has been pushed back since has been the branch date. The release date is still set for one week from now, either this coming Saturday or Sunday. It's simply a matter of developer convenience. We can't branch while developers are still putting major bits into the tree because it would result in developers having to then commit the work to both branches. -Matt
Re: Journals and jscan
: 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 <[EMAIL PROTECTED]>
