gene heskett posted on Fri, 08 Apr 2011 06:50:36 -0400 as excerpted:
> On Friday, April 08, 2011 06:23:40 AM Duncan did opine:
>
> I will do that, and reboot in a few minutes. Because I have /var on its
> own partition, this always involves a tap of the reset button as the
> shutdown gets to:
> turning off swaps -f and hangs due to /var already having been unmounted
> & it can't get a lockfile opened.
>
> I know, that is not preferred, but having had a couple of instances
> where an error made / into read-only, that prevented the logs from
> recording any trace of the error, and was pure hell to troubleshoot, the
> first time I just re-installed. So I am adament about /var being on its
> own partition just to prevent the loss of logging when the main / goes
> tits up. IMO, the shutdown scripts that cannot work under those
> conditions are hopelessly broken.
FWIW, here /var is on /, but /var/log is on its own partition.
I believe I mentioned the disk overheat I had. Well, at the time I didn't
have another drive at hand and one the drive cooled down, the problem
didn't seem to be getting seriously worse. And I had partitioned the
thing up with duplicate/backup partitions for much of the system, so
that's what I ended up booting, some of the backups.
But I ended up with a / of one age, /usr of another, and the current /var,
each on its own partition separate from the other two. That was terrible
to try to sort out, as what the package manager installation database (in
/var/db) had to say didn't match the reality of what was installed on /,
which didn't match /usr. I started by reinstalling all the packages (on
Gentoo, but from binpkgs, which I always made it a point to build, as they
come in handy for all sorts of reasons, the binpkgs partition was
thankfully current) the package database said were installed anyway. That
got me back to in sync there, but because the old versions were different,
where the actual filenames differed as where libraries had been updated, I
now had "orphan" old versions that weren't removed as they would have been
in a proper upgrade. It took me months to cleanup that mess, a bit at a
time as I realized there were yet more orphans lurking around!
So when I did the partition plan for the new system, I decided that
everything the package manager installed to along with its database in
/var/db, should be on the the same partition, so if it happened again, the
database and all package installations would at least be in sync with each
other, no matter which partitions I ended up mix and matching, and how old
the backup partition was that I ended up using.
By contrast, /var/log really does need its own, relatively small,
partition. Several times I've had various bugs runaway with the logging,
and end up filling up the log partition, normally only about a third of
capacity even right before the weekly logrotates. The relatively small (1
gig... I still find it a bit ironic to call that "small" but anyway) log
partition has kept the issue from filling up /, while the small spare
capacity, always under a gig, means I find out about it far sooner than I
would if it were on a partition with double-digit gigs or more of spare
capacity.
But the "everything the pm installs to and the pm database" policy for /,
has meant a bit of a strange setup, with several bits of /usr either as
their own filesystems (/usr/local, since it contains a lot of local
scripts and the like I'd hate to have to reauthor) or symlinks onto
filesystems mounted elsewhere (/usr/src, for instance, is a symlink to a
subdir of my only raid-0 backed filesystem, since it's locally cached net
data, with the distro package tree as another subdir on the raid-0, with
the same local-cached net data reasoning).
>> Anyway, assuming those unreadable-by-root files are indeed filesystem
>> damage as I expect, there's a fair chance it's due to data=writeback on
>> that filesystem, be it ext3 or ext4. For both of them, if it were my
>> data on the filesystem and unless it was something I was comfortable
>> sticking on a RAID-0 without redundancy or backup, I'd take tune2fs and
>> ensure the filesystem was marked data=ordered in the filesystem itself,
>> Additionally, make sure your mount options (or remount, for root)
>> include the data=writeback option.
>
> What is the syntax to extract that info?, the -l output as shown below
> doesn't say.
I don't see it either, which means that if it's not set at mount time by
either the mount command or fstab, the kernel defaults apply. And we know
that data=writeback was the kernel default for part of the 2.6.3x series.
> I'm off to do a full powerdown reboot, and at least 1 full cycle of
> memtest86. /.autofsck touched. With 4Tb of fscking to do, I won't say
> brb. :-)
You got /that/ right!
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
