Comment 11 for bug 397745

On Tue, May 03, 2011 at 12:44:06AM -0000, Phillip Susi wrote:
> 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.

The patch was posted to the mailing list.

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

Well... My backup partition "sprung a leak" (i.e. a corruption) after
some time. My machines have average uptimes that exceed the
fsck-interval by a factor of two: I didn't have a powerfailure cause
the corruption.

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

I don't feel comfortable shrinking existing filesystems. But
yeah, Maybe that's possible.

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

Well, there are several parts that are special.

First there is the root. I'm currently considering upgrading my home
workstation from Jaunty to Natty. I had the sense to partition my
drive to have several "sized-for-a-root-partition" partitions. So
instead of having to upgrade my root I can reinstall on one of the
other partitions and decide to switch when I'm satisified it works. (I
could upgrade the existing jaunty risking unable to go back if
something doesn't work well enough to be workable, or reinstalling
over the current install risking losing configuration information I
spent hours on generating).

Secondly there is "/home" which consists entirely of "to be preserved
in case of upgrade" user-data. Having that in a separate partition
helps.

If my /var/www grows out of the /root partition, I simply move it to
/home/www and symlink: ln -s /home/www /var/www .

So, I would argue that / and /home should be on separate partitions,
while all the others I don't care too much about.

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

tar and dump are oldfashioned and don't provide the features modern
people demand from their backups: Instant access to version of the
past. And instant access to a single file.

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

That is a good idea.

 Roger.