> That sounds like a good plan. The current filesystem block size is 8192 and
> the partition in question has a size of 37846368 512-byte sectors. What's the
> rule of thumb to calculate the minimum block size that will stop
> triple-indirects given such parameters?

It will solely depend on the file size and block size.
However I don't know the numbers involved....

Some experiments using:
    rm big; 
    dd seek=<n> count=1 if=/dev/zero bs=8k of=big 2>/dev/null;
    ls -sl big

There are 96 slots (presumably in the inode) that will reference 1k frags.
Beyond that all allocations seem to be in 8k blocks.
First indirection 8k buffer - 2k blocks of 8k each.
Second indirection 8k buffer - 2k blocks each refs 8k of data.

	blocks	blk-sz	size	total
Inode	96	1k	96k	98304
first	2k	8k	16M	16,875,520
second	2k*2k	8k	32Gb	34,376,613,888
third	2^33	2^13	70Tb	7x10^13

I suspect that the first extension is proportional to the
square of the block size, and the third to the cube of
the block size.

However ls -s does show some lurking bugs!
For the above command:
	<n>	sectors	blocks
	0	16	1	data
	1..11	32	2	data + pre-alloc
	12..	48	3	data + extn + pre-alloc
	..2059	48	3
	2060	80	5
	2061..	64	4	data + 2*extn + pre-alloc
	4196363	64	4
	4196364	112	7
	4196365	80	5	data + 3*extn + pre-alloc

Something definitely goes awry when the file is near a boundary.
Maybe the block before the write is being allocated?
Or is it the one after??
Except it gets it wrong on the boundary!
Or I have miscounted slightly.

Also, at the limit, <n>=2147483647 only used 4 blocks?

	David

-- 
David Laight: david@l8s.co.uk