Re: Database Usage of Unix FFS

pete_at_tecc.co.uk (Pete Bentley) writes:
>>>>>> lparsons_at_world.std.com (Lee E Parsons) writes:
>>>
>>> (I/O distribution considerations aside. Of course.)
>>>
>Well, I/O distribution matters...you can use 100% of the disk, but
>blocks from the last few files that are created may be scattered
>across the whole whole disk, hurting performance.

Sorry, I wasn't very clear. I wasn't suggesting that it isn't an important issue. I was trying to limit the topic so we didn't make this a bigger problem than it needed to be.

>>> 2) Since no deletes are happening you don't have to worry about holes
>>> in the data. ie) you won't have 100 meg in the middle of the drive
>>> you need to use.
>>>
>>> Even if you needed to add an additional datafile it would just get
>>> slapped on the end of the last datafile in one contiguous space.
>

[...]

>The 10% default value for minfree is designed to minimise these
>poor allocations by ensuring there is generally enough free space to
>allocate a block near to the previous one in the file.
>The maxbpg parameter is also there to improve allocation for general
>purpose filesystems...Only maxbpg blocks from a file will be allocated
>in a single cylinder group...further blocks will be allocated from
>another cylinder group, involving a seek to get to the next data
>block.

What happens in the case where a single file covers the entire disk? If you were writing an 100mb file over a 100mb disk all at once.

I assume that in this case every group would have maxbpg blocks of the file on it. On the next write, would an additional segment of maxbpg blocks be allocated on each group or would the FS spread chunks smaller than maxbpg across each cylinder group

>For what you are doing, putting a few big files on a big disk, it is
>tempting to suggest that a more traditional, SVR3-type filesystem
>might be more efficient...allocate a really small number of inodes,
>put all the files as few directories as possible and the SVR3 layout
>policy means you can get all the files contiguous if you create them
>on another f/s and tar or cpio them to their destination. Comments?

I tend to agree. Most of the issue seems to be aimed at defeating all the hard work CSRG did to make FFS a general purpose FS.

The answer may well be to acknowledge that the situation doesn't call for a general purpose anything and not use the FFS. Raw would seem to be the best answer but I have problems coming to that conclusion without going through this exercise. If I don't really understand how the data is layed out on the disk how am I ever going to make any recommendation with a straight face.

I smell a benchmark comming. :-}

-- 
Regards, 

Lee E. Parsons                  		
Systems Oracle DBA	 			lparsons_at_world.std.com