"Cahill, Earl" <[EMAIL PROTECTED]> wrote: >Just putting about a little feeler about this package I started writing last >night. Wondering about its usefulness, current availability, and just >overall interest. Designed for mod_perl use. Doesn't make much sense >otherwise.
I would think it could be useful in non-mod_perl applications as well - you give an example of a user's mailbox. With scp it might be even more fun to have around :) (/me is thinking of config files and such) >transactionalizing where I can. The whole system depends on how long the >dirsync takes. In my experience, dirsync is very fast. Likely I would have >dirsync'ing daemon(s), dirsync'ing as fast as they can. In some best case >scenario, the most data that would ever get lost would be the time it takes >to do one dirsync (usually less than a second for even very large amounts of >data), and the loss would only happen if you were making changes on a dir as >the dir went down. I would try to deal with boxes coming back up and >keeping everything clean as best I could. What's a `very large amount of data' ? Our NIS maps are on the order of 3 GB per file (>64k users). Over a gigabit ethernet link, this still takes half a minute or so to copy to a remote system, at least (for NIS master->slave copies) -- this is just an example of a very large amount of data being sync'd over a network. I don't see how transferring at least 3 GB of data can be avoided (even with diffs, the bits being diff'd have to be present in the same CPU at the same time). If any of the directories being considered by your module are NFS mounted, this will be an issue. Personally, I see NFS mounting as a real possibility since that allows relatively easy maintenance of a remote copy for backup if nothing else. -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
