lkml.org 
[lkml]   [1999]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.3.x wish list?
Date
Riley Williams wrote:
>Hi Ted.
>
> > One of the things which I'm planning on doing is changing
> > mke2fs's defaults based on the size of the filesystem it's
> > making. If it's making a large filesystem (where large is
> > probably bigger than, say, 200-300 megs), I'll change it to use
> > 4k block sizes and also reduce the number of inodes created
> > (since with a large filesystem, you generally don't need quite
> > so many inodes).
>
>Is the kernel limited to either 1k or 4k block sizes?
>
>If not, I'd suggest something along the lines of the following:
>
> 1. For partitions less than 250M, use 1k blocks.
>
> 2. For partitions between 250M and 500M, use 2k blocks.
>
> 3. For partitions between 500M and 1G, use 4k blocks.
>
> 4. For partitions over 1G, where memory is mapped in 4k units,
> use 4k blocks.
>
> 5. For partitions not covered by the above, use 8k blocks.
>
>Comments?
>
>Best wishes from Riley.
>

I dont' think this is "evil" but ...


MS saw an archetecture problem (FAT system sucks up space relative
to number of blocks on disk) and "fixed" it by makeing block size
relative to file system size. Now their FS's suck up huge chunks
data for empty files.

We see an archetectural problem (FSCK takes to long to run), and
are considering fixing it by making really big blocks. Now, I
know there are other advantages, but every time the block size
doubles, the fragmentation loss doubles. If we could stand the
complexity, a buddy system for pieces over a small limit and under
page-size might work, but I think we are fixing the wrong thing.


We need to fix the FSCK problem -

My choice for the wishlist - filesystems that aren't modified after
a certain amount of time, could by synced (sort of like a disk going
to sleep), marked clean, and essentially remounted read-only, with
two provisos:

1. If anyone wants to change the partition, put a 1 in the dirty bit,
write that block, then continue as read-write, like a disk waking
up from power-saving mode. Ten minutes might be reasonable.

2. atimes would need to be dealt with. If atimes are enabled, we would
want to have three states - clean, clean-except-atimes, and dirty.
You don't need to sync if the atimes are the only dirty piece,
because you can't fix them and it won't hurt if they are not fixed.

This would allow most users to not have to fsck /, /usr, /dos,
and /home/JohnDoe if JohnDoe has a seperate home and never logs on.


Parts of a partition could "fall asleep" independently, various
optimizations are possible... But for a lot of people, this would
turn 1 hour into 15 minutes.


-----kbealier.at.stny.lrun.com-------------------------------------
THE LESSER-KNOWN PROGRAMMING LANGUAGES #12: LITHP
This otherwise unremarkable language is distinguished by the
absence of an "S" in its character set; users must substitute
"TH". LITHP is said to be useful in protheththing lithtth.


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.146 / U:9.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site