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
ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
