On 3/29/11 9:05 AM, Theodore Tso wrote: > > On Mar 28, 2011, at 2:06 PM, Eric Sandeen wrote: >> >> No other fs that I know of enforces this "don't fill the fs to >> capacity" common sense programatically, though. > > Actually, we (ext2) copied this from the BSD Fast File System (FFS) > which used a default MINFREE of 10%. For ext2 we decided to bring > it down to 5%. FreeBSD currently uses 8% as their default free > ratio. Clearly I don't know enough filesystems, I guess ;) Should have said "linux filesystem" perhaps. > The decrease does seem to be relative to the percentage of free > space, from empirical experience, although no one I know of has done > a formal analysis of the slowdown. A lot depends on your workload, > how much memory pressure you place on your system, etc. I've > actually started seeing slowdowns starting as early as 80% full when > you're trying to allocate large chunks (1M to 8M) at a time, although > this isn't something where I've gathered hard data; just what I've > noticed from looking at different systems and their performance > characteristics. > > Fortunately disks are cheap, and lots of people end up buying far > more disk space than they need, and so they naturally keep their file > systems well under 75-80% full. > > If someone wants to add some tuning parameters to mke2fs.conf, so > they can set their own personal default free ratios, or even > min_reserved_blocks and max_reserved_blocks settings, that's probably > a reasonable patch to e2fsprogs that I'd be willing to accept. Hm I thought I had sent that, but it was only for the other two semi-controversial behaviors. :) I agree, it seems like at least a decent first step to make it more site/admin-configurable. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html