Hi, On 11/23/2006 5:20 PM, Kern Sibbald wrote: > On Thursday 23 November 2006 16:39, Martin Simmons wrote: > >>>>>>>On Thu, 23 Nov 2006 08:29:25 -0500, Bill Moran said: >>> >>>On Thu, 23 Nov 2006 10:38:41 GMT >>>Martin Simmons <[EMAIL PROTECTED]> wrote: >>> >>> >>>>>>>>>On Wed, 22 Nov 2006 17:26:47 -0500, Bill Moran said: >>>>> >>>>>On Wed, 22 Nov 2006 23:11:59 +0100 >>>>>Andras Horvai <[EMAIL PROTECTED]> wrote: ... >>>>>If I'm understanding this correctly, there's no reason Bacula can't do > > the same > >>>>>thing with file volumes. If it writes an EOF marker every 4G (which > > it seems to, > >>>>>based on your output) it can seek() to the within 4G of the data it > > needs, then > >>>>>it only needs to read() through a maximum of 4G to get the data.
No, because 1) a volume file can be shorten than whatever you set up in case there is no more data to add. At least that's what I assume. >>>>Using EOF markers like that in a file won't work, because there is no > > fast way > >>>>of seeking to an EOF marker (unlike on a tape). and 2), also AFAIK, puting an EOF into a tape file effectively closes the file and thus you couldn't add anything to it. (Sounds like setting a maximum size for a volume :-) There is no data representing an EOF mark in files, that's something only the hardware of a tape drive manages. >>>?? >>> >>>If Bacula knows it's writing a file marker every 4G, why can't it just use >>>fseek() to skip forward? >> >>I was just being pedantic, because it doesn't write anything for the EOF >>marker. > > > Perfectly true, but ... > > Bacula *does* write something every 1GB (by default), and that is a JobMedia > record. This is how Bacula finds and seeks to files quickly on tape. > Unfortunately, the Bacula fseek() code for disk storage does not work in all > cases. I've tried, and after a *lot* of time spent on this I have not found > the problem so I give up as there seem to be many other important tasks to > do. > > As I have explained before on this list, all you need to do is turn on > FILE_SEEK in <bacula>/src/version.h, recompile Bacula and find where the bug > is, then submit a patch. You will know the patch is good when you can run > *all* the disk based regression scripts with FILE_SEEK turned on without any > failures (the last time I tried, yesterday, there were four). > > What I haven't mentioned before is that as a reward, I offer the author of > the > patch not only a big thanks, but a dinner at any restaurant of his choice in > Lausanne, Switzerland (or any city where I happen to be if/when we meet). I > leave it to you to figure out how to get to Lausanne :-) Oh, good, any recommendations what books I should read to get a little understanding of C/C++? I'm quite sure there are some interesting restaurants in Lausanne, or wherever we would meet... ;-) Arno -- IT-Service Lehmann [EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
