If it is root that is writing, it will use the reserved space anyway so
depending on the reserved size it will take longer or shorter for
root to fill the fs whiel others can't write to it.
There might be fs that will not have any root activity, so a root cushion
is not needed. If for some reason you need emergency space you can always
borrow from other fs.
If you read my original message, you will see that I said this was
mostly true for the /usr and /var partitition, where root does need to
write log files, so it's important that root have a cushion.
> The second
> reason is that ext2's fragmentation-avoidance algorithms work best when
> there a certain amount of slack space reserved in the filesystem (i.e.,
> we want to leave some amount of choice for the block allocation
> algorithsm to choose optimal blocks to avoid fragmentation). That's why
> -m is represented as a percentage, and why 5% is used as the default.
If the reserved space is used for allocations then in the end also the
reserved space will be fragmented. In that case it all depends on the
dynamics on the fs. But sooner or later you will need to defragment in
order to improve fs performance and restore the contigious reserved
space.
It depends on what how big the files you are writing. It's not
necessary for the free space to be contiguous; just large enough so that
files written to the disk can still be contiguous. For example, for an
5% of 8 gig is 40 megs. If most of the files you write are smaller than
1 meg, it's likely that the files can be stored contiguously, even if
the filesystem only has 5-10% free space on it.
It is not that I question the use of reserved space. I just want to have
finer control over it. In the end it is just a tuning parameter. The
default can still be 5%. Allowing fraction percentages might also do
the job...
That's reasonable. The next time I mess with tune2fs and mke2fs, I'll
see what I can do on that front.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/