[Tfug] Mount and Filesize Issues
John Gruenenfelder
johng at as.arizona.edu
Tue Jun 2 08:03:54 MST 2009
On Tue, Jun 02, 2009 at 09:31:36AM -0400, Charles R. Kiss wrote:
> Hello Tucson,
>
> Apparently, in /var/log my kern.log is about 3.4GB, a file called
> messages is 3.4GB, and sys.log.1 is 3.4GB.
>
> I tried a lot of e2fsck -y -f -b with different blocks to get an old
> backup drive to mount with no luck, so I imagine the files contents are
> all related to these exercises.
>
> How do I modify the files contents to reduce their size, or do I just
> eliminate their contents completely? cat /dev/null /var/log/sys.log etc.
Normally, you would just wait for the normal cron log rotating scripts to do
their jobs. But, in this case you know what's eating all that space. For
those particular scripts, I think it should be sufficient to simply delete the
files in question and then restart syslogd and klogd. On Debian systems, the
scripts do to this are /etc/init.d/klogd and /etc/init.d/sysklogd.
> How do I get that old drive to mount???
>
> I moved my computer from one room to another and maybe I yanked out the
> backup drive's USB while it was mounting or something. I was also using
> an old USB 2.0 hub that someone lent me, it worked the firsttime, maybe
> it's unrelated.
>
> I think my computer thinks the backup drive an ext2 because it won't read
> a valid table under an ext3 mount, but I'm sure it started as an ext3. I
> made the mistake of e2fscking it with the -y -f options and I ended up
> with alot of files and directories in the lost+found, but many are
> missing.
I'm a little confused by this. Running e2fsck with -yf doesn't seem like such
a bad idea as you'd otherwise be there for ages, pressing y over and over for
cryptic messages about broken inode numbers. And, since you were able to look
at the contents of lost+found, doesn't that mean you were able to mount the
drive?
> Also, my / partition is 100% full for some reason (var is on a separate
> partition), so I'm working on that. I guess I just found out that
> /proc/kcore is 2.9GB; is that normal.
Everything in /proc is virtual so it doesn't occupy any space. And kcore
allows direct access to the memory on the machine. It should be equal in size
to the amount of memory the kernel has access to (installed RAM minus any
integrated video memory minus any RAM explicitly denied the kernel via a mem=
switch at boot time).
A 100% full / you probably want to fix right away, especially if /tmp is not
on a separate partition, since you could experience problems logging in or
running some programs which require any space in /tmp.
--
--John Gruenenfelder Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for PalmOS -- http://weaselreader.org
"This is the most fun I've had without being drenched in the blood
of my enemies!"
--Sam of Sam & Max
More information about the tfug
mailing list