On Mon, Apr 23, 2012 at 03:22:52PM +0300, Touko Korpela wrote:
> > Finally, the only file system where someone is likely to be creating
> > that is this small in this day and age is the /boot filesystem --- and
> > there, even if the drive using 512-byte emulation, performance isn't
> > an issue since no one is executing out of /boot, or even modifying it
> > very often.
>
> Yes, /boot is my primary worry.
Yes, and the performance hit only really happens when you need to do a
read-modify-write cycle. And /boot doesn't get modified very often
--- only when you update a kernel, and even when you do, it's mostly
large files which will generally be contiguous. So the performance
hit is barely measurable.
> A thing to consider is that "dumb" SSDs and
> USB sticks/memory cards are more common than "smart" SSDs.
(a) dumb SSD's still had to work well on Windows XP, and hardware
designs are conservative, so it's not clear to me this is really a
huge issue. And (b) USB sticks/memory cards are again primarily used
for file interchange, where performance is not a big thing. (It's
really random 4k writes where the read-modify-write cycles really
hurt. For big files, we where we issue a large contiguous write
transaction, you only do the read-modify-write cycle for the first and
last 4k block and that's not a big deal.
> And maybe some wants to resize such small filesystem bigger but resizing
> can't change blocksize larger.
... and how often do you start with a file system *that* small?
> Still I think that at least filesystems that are larger than about 50-100MB
> in size default blocksize should be 4096.
You're certainly entitled to your opinion. One of the reasons why
this policy is not hard coded, but can be easily modified via
/etc/mke2fs.conf is so that sysadmins can make changes for what is
most appropriate for their systems.
Regards,
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
