-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/02/2011 12:29 PM, rew wrote:
> My configuration is maybe a bit extreme. I'm happy to have provided a
> patch to e2fsck to have improved fsck performance from about 3 months
> to "only a day". Ted however hasn't moved to integrate my patch.

Ahh, is there a bug filed for that with the patch attached?  If e2fsck
can be improved to handle this kind of fs better then that seems worth
pursuing.

>> You could also just disable the periodic fsck.
> 
> You think it doesn't serve any purpose? Why not disable it for
> everybody?

I've been advocating that for years, but Ted still thinks it is a good
idea and it seems that the Ubuntu devs don't want to deviate from
upstream on this.

> And F.. bad lUCK to those who upgrade their ext3-4-5 filesystem over
> the years and keep their data. And those that happen to install Ubuntu
> as a backup-server using backuppc can go f... themselves.

Or come up with creative ways to break their fs into smaller chunks,
which can not be prescribed as a default policy.

> Right. But having the system set up by default in a sensible way means
> it is possible to realize that this is necceary and adapt a system to
> this setup instead of requiring a full reinstall.

Huh?  What is sensible?  My guess is that what is sensible to you is not
for most others.  Also you do not have to do a full reinstall to break
up the fs into smaller chunks if you realize a certain area is amassing
a huge collection of files.

> All this would have put someone with one big partition in big trouble
> with having to install new hardware for the partition. 

Sure, but again, this is not a common occurrence and can't really be
addressed by default.  What parts of the fs do you split off?  Is it
/home that is the problem?  Or /var/mail?  Or /var/www?  It depends.
For most users the problem is not having tens of millions of inodes
slowing down fsck, but simply having the hd divided into different
partitions, one of which can run out of space while the others have plenty.

> And if you have one of those applications and run backuppc and/or have
> a server that backs up a whole bunch of workstations you'll end up
> with lots of files like me.

It seems that at least Ted feels that this sort of thing is better done
with tar or dump or something instead of copying all files from each
machine and then repeatedly and deeply hard linking them, or to use an
fs that is designed to be able to do that sort of thing well, like
btrfs.  Hopefully if/when this becomes popular, btrfs will be positioned
to handle it well.

Continuing to push the envelope and either enhance fsck or design a new
fs like btrfs are worthy endeavors, but at this time, there does not
seem to be a sensible change to the default policy that would benefit
more people than it would harm.

I am a bit curious though, about what you think of an idea that has been
brewing in the back of my mind for some time.  That is to make use of
LVM in such a way that a default install can at least create a separate
/home volume, but leave most of the space unallocated at install time,
then have a manager program notice when a volume is close to full and
automatically extend it as needed.

One of the reasons that Collin has resisted adding any more default
partitions is because the msdos partition table is fragile and adding
more partitions puts more stress on it and tends to cause more breakage.
 It also invariably ends up causing some users to have problems with one
partition filling up but there being plenty of space left on the
other(s).  I think using LVM could satisfy all of these concerns since
only one actual partition is needed, and everything else is just a
logical volume allocated from there.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2/T9IACgkQJ4UciIs+XuIkvQCdF0pra0IzR2/OITbDUkcRBTcN
AQgAmQGwRaeUdyj6lQjEI1rtXNxqxU5/
=RU8/
-----END PGP SIGNATURE-----