When discussing inodes and data blocks, I know Solaris creates these data blocks with a total size of 8192b, divided into eight 1024b "fragments." It stores data in "contiguous" fragments and solaris doesn't allow a file to use portions of two different fragments. If the file size permits, then the file is stored in the "n" number of fragments within a single data block.
My question is this: if I have a file that is larger than 8K, which means it will need more than one data block, does solaris store the data blocks in a coniguous fashion? i.e., datablock1, datablock2, datablock3, etc. my instincts tell me it has to, otherwise the file becomes "fragmented." any help is appreciated.
Blocks not currently being used as inodes, indirect address blocks, or storage blocks are marked as free in the cylinder group map. This map also keeps track of fragments to prevent fragmentation from degrading disk performance.
It's posible that in some circunstances the file systems become
fragmented (see the output of fsck). In that case, use the tunefs.
The Block size and fragment size can be customized when you create the filesystem. If you use the "quot -c" , you can determine
the number of files of that size, and a cumulative total of blocks containing files of that size or a smaller size.
example:
quot -c /opt
/dev/rdsk/c0t0d0s3:
0 1 0
1 988 988
2 292 1572
3 227 2253
4 139 2809
....................................
1336 1 90691
1376 1 92067
1384 1 93451
1584 1 95035
1752 1 96787
2047 16 155355
if you think that the default sizes (for blocks and fragmets) is not the better; take a backup create the FS with your values, and restore the backup (using tar).
Regards. Hugo.
Hi, well you're assumption is right ufs will allocate a large files into contiguous datablock and, of course, in contiguous fragments into another datablock if is needed. AS an example imagine we have a 11264 Bytes file, ufs will store it into one datablock plus 3 fragments of the next datablock.
What happend with the remaining space in the datablock? well it will be share for another file storage.
hope it helps 
I appreciate the help. I guess I should have followed my instincts in assuming that data IS stored in contiguous data blocks.
thanks to all.
Actually, that is not correct. Data blocks may not be contiguous. When a file grows and needs a new data block unix will try to find one nearby. But it's willing to take any data block if it must. Think about the case where a program runs away and writes a file that completely fills up the file system. That file had to use every available block. It will be severely scattered. Normally we call such a file "fragmented", which means that the blocks have been allocated all over the disk. Don't confuse that with "fragments" which are pieces of a block allocated to the end of a file.
Modern disks have a variable geometry and its no longer possible to tune the rotational delay to be optimal for the entire disk. But in the old days the rotational delay was used to help ensure that disk blocks were never contiguous in a physical sense. That was because unix could not issue the next read in time before the next block rotated away.