Hi, On 3/20/2007 10:23 PM, Hans Manz wrote: > Kern Sibbald schrieb: >> When Bacula is scanning, listing, or restoring (depending on the exact >> options) from a volume, it will read to the end of the volume, so with your >> scheme, such operations will fail. > > I don't mind if these operations would fail just during the moment when > bacula is about to recycle a volume since the old data is invalidated in > right that moment anyway.
The problem is that Bacula handles file based volumes similar to tapes: You can start writing at the beginning (for files, this implies the file is truncated at position 0), or position to the end of volume and add data there. For tapes, there's no option to start to overwrite data somewhere in between that's really usable, and so Bacula doesn't to it for files. I suspect that Kern, while not liking such a mode of operation himself, would consider a patch to add that ability, but that would be a really huge patch and hard to verify for correctness. >> Because when a file is overwritten and not truncated, it ends at the >> original >> size of the file, when a tape is overwritten, it ends at the end of the new >> data. > > Am I missing any arguments here? When I write 20MB on a 4GB tape, the > size of the tape will remain 4GB. The logical size of the data on tape, i.e. the offset of the End Of Tape mark after your write, would be at 20 MB. > When I write 20MB on a 10MB file, the > size of the file will become 20MB. But that would require another operation than "open for writing and truncate at offset 0" which is simply not easily implemented. Anyway, I consider your suggestion worth a feature request, though I guess you'll have a hard time implementing it. >> No, good systems such as Linux do not fragment the disk nor do programs such >> as Bacula fragment the disk. The disk becomes fragmented only if there are >> multiple processes writing the disk at the same time, or some files are >> deleted. The administrator (I used the word user in the last email) can >> control this behavior if it is important. > > Yes, this is a point. To let programs avoid backdraws instead of leaving > this to administrators is another. > > Well, the world out there will not miss very much, wether bacula > truncates anything or not. True. > But what I am really fed up with are arrogant > open source developers who think their users were too stupid. Understandable, but I don't think Kern belongs into that category. Why would he discuss these matters if it were so? From a previous mail: >>> I've been playing with bacula and noticed a strange behaviour. I have >>> configured a Pool with disk volumes of size 100MB each. On one run I >>> wrote three tapes. Then I've deleted the catalog and recreated it with >>> the scripts shipped with bacula. On the next run bacula took the first >>> tape, seeked to the end and started to write another 100MB appended to >>> the volume resulting in volume of size 200MB. I think this is not a >>> user-expectable behaviour of "Maximum Volume Bytes", i.e. I think this >>> is a bug, no? >> No, this is not a bug, and what you write above is not possible with Bacula. >> >> You have left out some information. If I literally do what you say, Bacula >> will *never* write to volumes that have been previously used. If it did so, >> it is because you specifically told it to do so (and left that out of your >> comments above). > > Of course it is a bug. If I use Maximum Volume Byte I want the volumes > beeing given bytes maximum. Keep in mind that Maximum Volume Bytes are stored in the catalog, for each volume. But you wrote that you cleared the catalog, so I suspect that information is not in there. Try the 'llist volume=...' command to see what the catalog contains, regarding that volume. > Exceeding this limit is a not wanted > behaviour and thus it must be considered a bug. > > What should I have left out? How could I explicitly tell bacula to write > to a volume that (should) not exist in the catalogue? As far as I know, you can't. If Bacula encounters a volume that's not in the catalog, it will not use it. If you added it to the catalog, you have to change the attributes to the values you want. When you have a volume added, not labeled, that already contains data, Bacula will read the label, recognize it as empty - because that's what the catalog says - and positions it to the end of data for subsequent writes. The EOD is not after the volume label, but after the data previously written to tape. You end up with an unusable volume because the catalog does not represent what actually is on the tape. One of the reasons to not use the 'add' command but to overwrite the tape and label it again. In other words, I guess you used the 'add' command, and this is what you didn't tell us in your initial mail. Arno > /hm > > ------------------------------------------------------------------------- > 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 -- 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
