On 04/07/10 01:05, Craig Ringer wrote:
> Phil Stracchino wrote:
>> It is possible right now to open more than one file-based volume at a
>> time.
>> You simply need to define multiple storage devices under the same
>> storage daemon; each device can have one volume open at a time.
> 
> Yep. My suggestion was merely a way around the inconvenience and
> configuration bloat required to do this at present. I'm saying it
> shouldn't be necessary to go through all that just to achieve
> concurrent disk writes.

I hear you.  I think it's partly a symptom of the principle that being
required to handle a great number of different possible configurations
tends to make it a little difficult to optimize for any specific one of
them.

> I'm also using a striped RAID-6 volume across eight 1TB disks, which
> means access patterns are going to be somewhat random anyway.
> Fragmentation just isn't a big issue.

Yup, I have a similar configuration myself - eight working disks plus
hot spares on RAIDZ2.  I really don't concern myself about fragmentation
on it; but by the same token, I really don't concern myself about
interleaving either.  On disk volumes, I really don't find it to be an
issue (and so far I've found it comparatively little issue on LTO tape,
either).

>> The odds are good
>> the data will actually end up in the same places on disk; it will just
>> appear, from the point of view of scanning volumes, to be unfragmented,
>> because the disk system hides the fragmentation from you - exactly as it
>> is supposed to.  As previously mentioned, this can be overcome
>> essentially only by using a complete custom filesystem and disk driver
>> that treats disks like tapes.
> 
> Actually, you can do a pretty good job just by using
> posix_fallocate(...) to inform the file system of how much space you
> expect to need.
> 
> The sd doesn't currently appear to use posix_fallocate(...) at all.

I'll freely admit I haven't looked much at the low-level code in that
area.  (As a matter of fact, it's been embarrassingly long since I've
looked at the low-level code at all; despite my good intentions about
returning to active development, I've found other projects consuming
most of my time.)

> Of course. I do much the same thing myself. I'm just suggesting that
> perhaps this sort of thing shouldn't have to be built by each Bacula
> user, but perhaps be built in to the system to make it a bit more
> practical and convenient?

Now that automatic truncation of purged volumes exists, automatic
deletion is a pretty small step.  I can't see that there would be any
objection to that change, if you were to submit a proposal on the dev list.

> I don't mean to come off as a grumpy/demanding user. I'm not saying "you
> should do this!", I'm seeking comments and opinion on whether these
> things are worth doing. I may well tackle them myself if so, I just
> don't want to waste my time on things that will get rejected.

By all means contribute code.  :)  You're right to make sure the
proposed changes will be accepted first though.


-- 
  Phil Stracchino, CDK#2     DoD#299792458     ICBM: 43.5607, -71.355
  alaric AT caerllewys DOT net   alaric AT metrocast DOT net   phil AT 
co.ordinate DOT org
         Renaissance Man, Unix ronin, Perl hacker, Free Stater
                 It's not the years, it's the mileage.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users