Sarah Jelinek schrieb:
Daniel,

To clear up a misconception about MTB UFS. The maximum density of inodes that can be in a MTB UFS filesystem is 1 inode per megabyte of space. This does not mean that a megabyte of space is used for every file. It simply means you cannot have more than a million or so files per terabyte of storage.

So to fill up such a file system to 100 percent your average file size has to be 1MB - that's exactly what I said. I didn't say the block size was raised to 1MB.

Since also directories allocate inodes and are rarely filled with ten-thousands of files, the average file size on MT-UFS has to be even larger than 1 MB to fill the whole FS.

Luckily the limitation is only enforced in newfs/mkfs. You just have to redefine
#define MTB_NBPI        (MB)
in usr/src/cmd/fs.d/ufs/mkfs/mkfs.c, recompile, (re-)newfs and you're done.


The reason for this is simple, it could take days or weeks to fsck the filesystem.

I think this limit is way too high for "general purpose" use:

Filesystem             size   used  avail capacity  Mounted on
/dev/md/dsk/d200       309G   288G    17G    95%    /export
Filesystem             iused   ifree  %iused  Mounted on
/dev/md/dsk/d200     1535475 1037325    60%   /export


BTW a full fsck of above filesystem ran in ~33 Minutes and memory usage of fsck raised to 46 MB. Most of the time it spent in Phase 1 (Check Blocks and Sizes) - see below. So it would have been a wiser decision to raise the block/fragment limit to something larger than 8 kByte.

Phase 1 - Check Blocks and Sizes       ~24 Minutes
Phase 2 - Check Pathnames               ~9 Minutes
Phase 3 - Check Connectivity            <1 Second
Phase 4 - Check Reference Counts        <1 Second
Phase 5 - Check Cyl groups              <1 Minute
1535473 files, 151212388 used, 10602271 free (223755 frags, 2594629 blocks, 0.1% fragmentation)
Total: 33:12.95


Daniel
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Reply via email to