[gentoo-user] Freeing up disk space problem!!

[gentoo-user] Freeing up disk space problem!!

[trevor donahue]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

Hi everyone,
I'm experiencing a major problem right now. I've been using gentoo for
several months now and I simply lllooove it!
So here's the thing. When I use gentoo for a long time, even without
updating the current pack of installed software (emerge -uD world), I am
left without disk space... In situations like this I start deleting
/var/tmp/*, /tmp/*, /usr/portage/distfiles/*, maybe do even a
revdep-rebuild to fix something, but even then I'm left with no more then
100 mb, which obviously is not enough ...
So this time I googled a bit and I deleted all the /usr/share/doc/ and this
left me with 2.5 gb of space (wow).

So the questions are ... in cases like this, what should be done? what is
storing this much space? logs?

[-- Attachment #2: Type: text/html, Size: 808 bytes --]

Re: [gentoo-user] Freeing up disk space problem!!

[Alan McKinnon]

On Tue, 28 Feb 2012 11:37:44 +0000
trevor donahue <donahue.trevor@gmail.com> wrote:

> Hi everyone,
> I'm experiencing a major problem right now. I've been using gentoo for
> several months now and I simply lllooove it!
> So here's the thing. When I use gentoo for a long time, even without
> updating the current pack of installed software (emerge -uD world), I
> am left without disk space... In situations like this I start deleting
> /var/tmp/*, /tmp/*, /usr/portage/distfiles/*, maybe do even a
> revdep-rebuild to fix something, but even then I'm left with no more
> then 100 mb, which obviously is not enough ...
> So this time I googled a bit and I deleted all the /usr/share/doc/
> and this left me with 2.5 gb of space (wow).
> 
> So the questions are ... in cases like this, what should be done?
> what is storing this much space? logs?

The thing that is taking up your space is whatever is making big files
or lots of files.

Now that could be anything, you will have to look on your machine
yourself and tell us what it is.

Start here:

du -sh /*

Start with the biggest directory and recursively go deeper down into
the structure till you find the major space hogs.

Logs is one option, and a likely one. But by no means the only
possibility. So just run du and find what it is on *your* box.



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Freeing up disk space problem!!

[William Kenworthy]

On Tue, 2012-02-28 at 13:52 +0200, Alan McKinnon wrote:
> On Tue, 28 Feb 2012 11:37:44 +0000
> trevor donahue <donahue.trevor@gmail.com> wrote:
> 
> > Hi everyone,
> > I'm experiencing a major problem right now. I've been using gentoo for
> > several months now and I simply lllooove it!
> > So here's the thing. When I use gentoo for a long time, even without
> > updating the current pack of installed software (emerge -uD world), I
> > am left without disk space... In situations like this I start deleting
> > /var/tmp/*, /tmp/*, /usr/portage/distfiles/*, maybe do even a
> > revdep-rebuild to fix something, but even then I'm left with no more
> > then 100 mb, which obviously is not enough ...
> > So this time I googled a bit and I deleted all the /usr/share/doc/
> > and this left me with 2.5 gb of space (wow).
> > 
> > So the questions are ... in cases like this, what should be done?
> > what is storing this much space? logs?
> 
> The thing that is taking up your space is whatever is making big files
> or lots of files.
> 
> Now that could be anything, you will have to look on your machine
> yourself and tell us what it is.
> 
> Start here:
> 
> du -sh /*
> 
> Start with the biggest directory and recursively go deeper down into
> the structure till you find the major space hogs.
> 
> Logs is one option, and a likely one. But by no means the only
> possibility. So just run du and find what it is on *your* box.
> 
> 
> 

or "du|sort -rn|less"

hogs are at the top ...

BillK

Re: [gentoo-user] Freeing up disk space problem!!

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1301 bytes --]

On Tuesday 28 Feb 2012 11:37:44 trevor donahue wrote:
> Hi everyone,
> I'm experiencing a major problem right now. I've been using gentoo for
> several months now and I simply lllooove it!
> So here's the thing. When I use gentoo for a long time, even without
> updating the current pack of installed software (emerge -uD world), I am
> left without disk space... In situations like this I start deleting
> /var/tmp/*, /tmp/*, /usr/portage/distfiles/*, maybe do even a
> revdep-rebuild to fix something, but even then I'm left with no more then
> 100 mb, which obviously is not enough ...
> So this time I googled a bit and I deleted all the /usr/share/doc/ and this
> left me with 2.5 gb of space (wow).
> 
> So the questions are ... in cases like this, what should be done? what is
> storing this much space? logs?

Gentoo takes up more space than a conventional binary distro because of 
portage and source files in /usr/portage/distfiles.

Look at eclean to help you remove old package files no longer installed.

Also look at logrotate to help you automatically rotate, compress and delete 
old(er) log files.

As a matter of good practice I always fit /var/ on a different partition to 
guard against logs going overboard and running out of space.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: Freeing up disk space problem!!

[Nikos Chantziaras]

On 28/02/12 13:37, trevor donahue wrote:
> Hi everyone,
> I'm experiencing a major problem right now. I've been using gentoo for
> several months now and I simply lllooove it!
> So here's the thing. When I use gentoo for a long time, even without
> updating the current pack of installed software (emerge -uD world), I am
> left without disk space... In situations like this I start deleting
> /var/tmp/*, /tmp/*, /usr/portage/distfiles/*, maybe do even a
> revdep-rebuild to fix something, but even then I'm left with no more
> then 100 mb, which obviously is not enough ...
> So this time I googled a bit and I deleted all the /usr/share/doc/ and
> this left me with 2.5 gb of space (wow).
>
> So the questions are ... in cases like this, what should be done? what
> is storing this much space? logs?

Install sys-fs/ncdu and run it as root with "ncdu -x /".  It's gonna 
take a bit to scan everything, but after that you should be able to tell 
what's taking up all the space.

Re: [gentoo-user] Freeing up disk space problem!!

[YoYo Siska]

On Tue, Feb 28, 2012 at 11:37:44AM +0000, trevor donahue wrote:
> Hi everyone,
> I'm experiencing a major problem right now. I've been using gentoo for
> several months now and I simply lllooove it!
> So here's the thing. When I use gentoo for a long time, even without
> updating the current pack of installed software (emerge -uD world), I am
> left without disk space... In situations like this I start deleting
> /var/tmp/*, /tmp/*, /usr/portage/distfiles/*, maybe do even a
> revdep-rebuild to fix something, but even then I'm left with no more then
> 100 mb, which obviously is not enough ...
> So this time I googled a bit and I deleted all the /usr/share/doc/ and this
> left me with 2.5 gb of space (wow).

My usual suspect for disk space in /usr/share/doc is kdelibs, with the
doc use flag turned on it installs the whole kde api documentation,
which takes a lot of space ...  so I either set -doc for
kde-base/kdelibs, or just set -doc globally and just enable it for
things i now I might need... (note that that won't remove all of the
/usr/share/doc dirs / files, but removes most of the large ones...)


yoyo


> 
> So the questions are ... in cases like this, what should be done? what is
> storing this much space? logs?

Re: [gentoo-user] Freeing up disk space problem!!

[trevor donahue]

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

wow that was fast!!!!
thanks a lot guys!

done some research, turns out in home there is a .cache and the folder
chromium there takes nearly 600mb, cleared chromium browsing / download
history, cleared the cache. that freed it.

Nikos Chantziaras, thanks, will test it tonight

YoYo Siska, thanks for the good idea, put -doc in make.conf and "nodoc" in
FEATURES

On Tue, Feb 28, 2012 at 12:24 PM, YoYo Siska <yoyo@gl.ksp.sk> wrote:

> On Tue, Feb 28, 2012 at 11:37:44AM +0000, trevor donahue wrote:
> > Hi everyone,
> > I'm experiencing a major problem right now. I've been using gentoo for
> > several months now and I simply lllooove it!
> > So here's the thing. When I use gentoo for a long time, even without
> > updating the current pack of installed software (emerge -uD world), I am
> > left without disk space... In situations like this I start deleting
> > /var/tmp/*, /tmp/*, /usr/portage/distfiles/*, maybe do even a
> > revdep-rebuild to fix something, but even then I'm left with no more then
> > 100 mb, which obviously is not enough ...
> > So this time I googled a bit and I deleted all the /usr/share/doc/ and
> this
> > left me with 2.5 gb of space (wow).
>
> My usual suspect for disk space in /usr/share/doc is kdelibs, with the
> doc use flag turned on it installs the whole kde api documentation,
> which takes a lot of space ...  so I either set -doc for
> kde-base/kdelibs, or just set -doc globally and just enable it for
> things i now I might need... (note that that won't remove all of the
> /usr/share/doc dirs / files, but removes most of the large ones...)
>
>
> yoyo
>
>
> >
> > So the questions are ... in cases like this, what should be done? what is
> > storing this much space? logs?
>
>

[-- Attachment #2: Type: text/html, Size: 3100 bytes --]

Re: [gentoo-user] Freeing up disk space problem!!

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

On Tue, 28 Feb 2012 12:50:02 +0000, trevor donahue wrote:

> YoYo Siska, thanks for the good idea, put -doc in make.conf and "nodoc"
> in FEATURES

You may want to reconsider the latter. The doc USE flag controls extra
documentation, such as API stuff, while still installing man ages etc.
FEATURES=nodoc gets rid of everything.


-- 
Neil Bothwick

Ultimate memory manager; Windows, it manages to use it all..

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Freeing up disk space problem!!

[Alex Schuster]

trevor donahue writes:

> So here's the thing. When I use gentoo for a long time, even without
> updating the current pack of installed software (emerge -uD world), I am
> left without disk space... In situations like this I start deleting
> /var/tmp/*, /tmp/*, /usr/portage/distfiles/*, maybe do even a
> revdep-rebuild to fix something, but even then I'm left with no more
> then 100 mb, which obviously is not enough ...

Use eclean-dist and eclean-pkg (in app-portage/gentoolkit) to delete your
distfiles.

If you instantly need more space, reduce the amount of reserved space for
the superuser, which is 5% as default:
tune2fs -m 2 /dev/your/partition
Don't reduce it to 0, the lower this value is, the more fragmentation you
will get.

> So this time I googled a bit and I deleted all the /usr/share/doc/ and
> this left me with 2.5 gb of space (wow).
> 
> So the questions are ... in cases like this, what should be done? what
> is storing this much space? logs?

You need to find out for yourself. I sometimes simply do a du -mx
--max-depth=1 / to see which directory has what amount of data in it.
Repeat for interesting directories like /usr/share/doc, and you will see
what takes big space. Add a '| sort -n' to get sorted output. Or better
use sys-fs/ncdu which is interactive.

If you prefer something graphical, there are many alternatives:

Baobab in gnome-extra/gnome-utils
kde-base/filelight
k4dirstat in kde-misc/kdirstat
Konqueror -> View -> View Mode -> File Size View (or something like that
in English)
jdiskreport in sys-fs/jdiskreport-bin

	Wonko

Re: [gentoo-user] Freeing up disk space problem!!

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Tue, 28 Feb 2012 14:01:50 +0100, Alex Schuster wrote:

> If you instantly need more space, reduce the amount of reserved space
> for the superuser, which is 5% as default:
> tune2fs -m 2 /dev/your/partition
> Don't reduce it to 0, the lower this value is, the more fragmentation
> you will get.

Why is that? I would have expected more usable space to reduce the need
for fragmentation. I routinely use 0 on non-system filesystems.


-- 
Neil Bothwick

The dark ages were caused by the Y1K problem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Freeing up disk space problem!!

[Alex Schuster]

Neil Bothwick writes:

> On Tue, 28 Feb 2012 14:01:50 +0100, Alex Schuster wrote:
> 
> > If you instantly need more space, reduce the amount of reserved space
> > for the superuser, which is 5% as default:
> > tune2fs -m 2 /dev/your/partition
> > Don't reduce it to 0, the lower this value is, the more fragmentation
> > you will get.
> 
> Why is that? I would have expected more usable space to reduce the need
> for fragmentation. I routinely use 0 on non-system filesystems.

I read this often, and to me it seems to make sense. When a file system
is nearly full, writing a last big file will make the file being
cluttered along all those tiny places where some free space is still
left. And this probably already happens to some extent before the
filesystem is completely full. 

Now, which values for reserved percentage are good, I don't know.
This probably depends much on the typical size of files on that partition,
and usage patterns. For large movies on your data partition, it probably
does not matter, but for my system partitions (/root, /usr, /var, /tmp,
portage stuff) I just keep it at 5%.

With the benefit that I can instantly free some space in /var when it's
just become full, without needing to decide what to delete. Okay, in
practice this does not matter much because resizing the LVM and resizing
the FS is also a matter of seconds only.

	Wonko

Re: [gentoo-user] Freeing up disk space problem!!

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

On Wed, 29 Feb 2012 00:25:00 +0100, Alex Schuster wrote:

> > > Don't reduce it to 0, the lower this value is, the more
> > > fragmentation you will get.  
> > 
> > Why is that? I would have expected more usable space to reduce the
> > need for fragmentation. I routinely use 0 on non-system filesystems.  
> 
> I read this often, and to me it seems to make sense. When a file system
> is nearly full, writing a last big file will make the file being
> cluttered along all those tiny places where some free space is still
> left. And this probably already happens to some extent before the
> filesystem is completely full. 

But if you set m > 0, the filesystem will become full sooner, so
fragmentation will begin sooner (for non-root processes). 


-- 
Neil Bothwick

Did you hear about the blind prostitute? You have to hand it to her.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Freeing up disk space problem!!

[Alex Schuster]

Neil Bothwick writes:

> On Wed, 29 Feb 2012 00:25:00 +0100, Alex Schuster wrote:
> 
> > > > Don't reduce it to 0, the lower this value is, the more
> > > > fragmentation you will get.  
> > > 
> > > Why is that? I would have expected more usable space to reduce the
> > > need for fragmentation. I routinely use 0 on non-system
> > > filesystems.  
> > 
> > I read this often, and to me it seems to make sense. When a file
> > system is nearly full, writing a last big file will make the file
> > being cluttered along all those tiny places where some free space is
> > still left. And this probably already happens to some extent before
> > the filesystem is completely full. 
> 
> But if you set m > 0, the filesystem will become full sooner, so
> fragmentation will begin sooner (for non-root processes). 

Uh, really? I wouldn't think so. With m > 0, there is much space left, in
large contiguous chunks, even though the user cannot use it all. But there
should be no difference between writing files in terms of fragmentation.
The reserved stuff acts just like a quota, at least that's what I always
thought.

	Wonko

Re: [gentoo-user] Freeing up disk space problem!!

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

On Wed, 29 Feb 2012 02:05:41 +0100, Alex Schuster wrote:

> > But if you set m > 0, the filesystem will become full sooner, so
> > fragmentation will begin sooner (for non-root processes).   
> 
> Uh, really? I wouldn't think so. With m > 0, there is much space left,
> in large contiguous chunks, even though the user cannot use it all. But
> there should be no difference between writing files in terms of
> fragmentation. The reserved stuff acts just like a quota, at least
> that's what I always thought.

Yeah, that makes sense, so why should the reserved setting affect
fragmentation at all, unless you write so much data that the filesystem
would be full with a larger m? In that case, I'd prefer fragmentation to
a failed write.


-- 
Neil Bothwick

Don't just do something, sit there!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Freeing up disk space problem!!

[Alan McKinnon]

On Wed, 29 Feb 2012 00:25:00 +0100
Alex Schuster <wonko@wonkology.org> wrote:

> Neil Bothwick writes:
> 
> > On Tue, 28 Feb 2012 14:01:50 +0100, Alex Schuster wrote:
> > 
> > > If you instantly need more space, reduce the amount of reserved
> > > space for the superuser, which is 5% as default:
> > > tune2fs -m 2 /dev/your/partition
> > > Don't reduce it to 0, the lower this value is, the more
> > > fragmentation you will get.
> > 
> > Why is that? I would have expected more usable space to reduce the
> > need for fragmentation. I routinely use 0 on non-system filesystems.
> 
> I read this often, and to me it seems to make sense. When a file
> system is nearly full, writing a last big file will make the file
> being cluttered along all those tiny places where some free space is
> still left. And this probably already happens to some extent before
> the filesystem is completely full. 
> 
> Now, which values for reserved percentage are good, I don't know.

The 5% figure is completely arbitrary and dates back many years. There
was no good reason then for it to be exactly 5%, it just happened to
mostly work fine. Remember that was a time when 250M was a BIG drive. 5%
is 2.5K and that is about the size of the largest single file people
realistically were using.

So 5% wiggle room for root lets you manipulate the last single file
you were using when the drive filled up, and hence save the day. These
days 2TB file systems are common and 5% means 20G.

How many 20G files do you routinely have on a single file system? Media
drives aside, a few meg is still about the broad average file size. It
is just not realistic to reserve emergency wiggle room for root that
amounts to 20,000 average files.

It means there's no single sane default anymore. On my servers I set
reserved space to 100M or so as that's what I need. I reckon the
average person should keep it to somewhat larger than the biggest
single file you expect to store on that file system.


 
> This probably depends much on the typical size of files on that
> partition, and usage patterns. For large movies on your data
> partition, it probably does not matter, but for my system partitions
> (/root, /usr, /var, /tmp, portage stuff) I just keep it at 5%.
> 
> With the benefit that I can instantly free some space in /var when
> it's just become full, without needing to decide what to delete.
> Okay, in practice this does not matter much because resizing the LVM
> and resizing the FS is also a matter of seconds only.
> 
> 	Wonko
> 



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Freeing up disk space problem!!

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

On Wed, 29 Feb 2012 11:29:45 +0200, Alan McKinnon wrote:

> It means there's no single sane default anymore. On my servers I set
> reserved space to 100M or so as that's what I need. I reckon the
> average person should keep it to somewhat larger than the biggest
> single file you expect to store on that file system.

Do you mean the biggest single file you expect root to store on that
filesystem? Is there any point in reserving space for root on a
filesystem root does not need to write to, such as /home?


-- 
Neil Bothwick

Very funny Scotty.. now beam down my pants!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Freeing up disk space problem!!

[Alan McKinnon]

On Wed, 29 Feb 2012 09:57:19 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> On Wed, 29 Feb 2012 11:29:45 +0200, Alan McKinnon wrote:
> 
> > It means there's no single sane default anymore. On my servers I set
> > reserved space to 100M or so as that's what I need. I reckon the
> > average person should keep it to somewhat larger than the biggest
> > single file you expect to store on that file system.
> 
> Do you mean the biggest single file you expect root to store on that
> filesystem? Is there any point in reserving space for root on a
> filesystem root does not need to write to, such as /home?
> 
> 

No, I mean the biggest file.

When $LUSER fills up his drive it can be that root is the only user
that can properly mount and access the filesystem. So whatever the
$LUSER was doing that filled up the drive needs to be undone by root,
probably by shuffling stuff around.

There are other cases where root might want some reserved space too,
but fixing full drives is the only case I've ever encountered. 

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Freeing up disk space problem!!

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

On Wed, 29 Feb 2012 12:40:33 +0200, Alan McKinnon wrote:

> When $LUSER fills up his drive it can be that root is the only user
> that can properly mount and access the filesystem. So whatever the
> $LUSER was doing that filled up the drive needs to be undone by root,
> probably by shuffling stuff around.

I've never failed to fix that by deleting a file as the user that created
it, usually the partial file that caused the problem, but I can see why
you may want to keep a small amount reserved for that.

However, I still don't get the "-m 0 increases fragmentation" thing.


-- 
Neil Bothwick

My friends went to alt.california, and all they brought
me was this lousy sig.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Freeing up disk space problem!!

[Alan McKinnon]

On Wed, 29 Feb 2012 11:08:49 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> On Wed, 29 Feb 2012 12:40:33 +0200, Alan McKinnon wrote:
> 
> > When $LUSER fills up his drive it can be that root is the only user
> > that can properly mount and access the filesystem. So whatever the
> > $LUSER was doing that filled up the drive needs to be undone by
> > root, probably by shuffling stuff around.
> 
> I've never failed to fix that by deleting a file as the user that
> created it, usually the partial file that caused the problem, but I
> can see why you may want to keep a small amount reserved for that.
> 
> However, I still don't get the "-m 0 increases fragmentation" thing.
> 
> 

Yeah, that sounds like an old wives tale urban myth to me too

I'll be wanting to be seeing the output of real diagnostic programs


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Freeing up disk space problem!!

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

On Wed, Feb 29, 2012 at 02:11:41PM +0200, Alan McKinnon wrote:

> > I've never failed to fix that by deleting a file as the user that
> > created it, usually the partial file that caused the problem, but I
> > can see why you may want to keep a small amount reserved for that.
> > 
> > However, I still don't get the "-m 0 increases fragmentation" thing.
> > 
> > 
> 
> Yeah, that sounds like an old wives tale urban myth to me too
> 
> I'll be wanting to be seeing the output of real diagnostic programs

All that does, as far as I understand it, is to fool $user into having less
space available. So if the partition only has as much space left as is
reserved for root, he just can't write anymore.

It just means that before the drive gets physically full (which means that
files will fragment more), it will get logically full earlier. This is why
there can be expected less fragmentation under extreme circumstances (i.e. an
almost full FS).
-- 
Gruß | Greetings | Qapla'
I forbid any use of my email addresses with Facebook services.

When the going gets tough, the tough get going.
... and so do I. – Alf

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Freeing up disk space problem!!

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

On Thu, 1 Mar 2012 01:59:41 +0100, Frank Steinmetzger wrote:

> It just means that before the drive gets physically full (which means
> that files will fragment more), it will get logically full earlier.
> This is why there can be expected less fragmentation under extreme
> circumstances (i.e. an almost full FS).

And after three hours of video transcoding, you get a disk full error
instead of a somewhat fragmented file. So far, I've seen no reason to not
use 0 on non-system filesystems. After all, -m 0 only tells ext? to
behave like every other filesystem in this respect.


-- 
Neil Bothwick

I work with User-Surly Software.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: Freeing up disk space problem!!

[walt]

On 02/29/2012 02:40 AM, Alan McKinnon wrote:

> So whatever the
> $LUSER was doing that filled up the drive needs to be undone by root,
> probably by shuffling stuff around.

That's a shocking statement for a wannabe BOFH to make.  A *real* BOFH
would delete the entire $LUSER account and blame the nuclear tests in
North Korea for causing an unfortunate power surge at his data center.

Re: [gentoo-user] Re: Freeing up disk space problem!!

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

On Mar 1, 2012 7:02 AM, "walt" <w41ter@gmail.com> wrote:
>
> On 02/29/2012 02:40 AM, Alan McKinnon wrote:
>
> > So whatever the
> > $LUSER was doing that filled up the drive needs to be undone by root,
> > probably by shuffling stuff around.
>
> That's a shocking statement for a wannabe BOFH to make.  A *real* BOFH
> would delete the entire $LUSER account and blame the nuclear tests in
> North Korea for causing an unfortunate power surge at his data center.
>

Naah, North Korea explanation already used 2 days ago... time to use a new
reason...

Today would be: surge caused by harmonic oscillation between rotating
electric motors, you know, like the... building air conditioner!

... followed by some conversation with the management with the end effect
of shutting down the building AC but letting the data center AC still
operational ...

Rgds,

[-- Attachment #2: Type: text/html, Size: 1058 bytes --]

Re: [gentoo-user] Freeing up disk space problem!!

[Dale]

Alex Schuster wrote:

> If you instantly need more space, reduce the amount of reserved space for
> the superuser, which is 5% as default:
> tune2fs -m 2 /dev/your/partition
> Don't reduce it to 0, the lower this value is, the more fragmentation you
> will get.
> 

I have a question on this.  I have a drive that I use for movies and
such.  There is nothing OS related on that drive.  Would it be safe to
set this to say 1% or even 0?  Also, it is already set up with LVM and
ext4.  Can I change it even while there is data on there?  I ask because
I don't want to change it and find out my collection is gone.  o_O

Thanks.

Dale

:-)  :-)


-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] Freeing up disk space problem!!

[Alex Schuster]

Dale writes:

> Alex Schuster wrote:
> 
> > If you instantly need more space, reduce the amount of reserved space
> > for the superuser, which is 5% as default:
> > tune2fs -m 2 /dev/your/partition
> > Don't reduce it to 0, the lower this value is, the more fragmentation
> > you will get.
> 
> I have a question on this.  I have a drive that I use for movies and
> such.  There is nothing OS related on that drive.  Would it be safe to
> set this to say 1% or even 0? 

I'd say 1% is okay. For 0% I'm not sure, I avoid that, but maybe there
will be no noticeable difference at all. 

> Also, it is already set up with LVM and
> ext4.  Can I change it even while there is data on there?

Sure! Cool, isn't it. Just call lvresize -L +1G /dev/mapper/whatever or
something, and then resize2fs /dev/mapper/whatever.

> I ask because I don't want to change it and find out my collection is
> gone.  o_O

Of course, backups are always a good idea, but this is pretty safe. I
wouldn't worry about it.

	Wonko

Re: [gentoo-user] Freeing up disk space problem!!

[Dale]

Alex Schuster wrote:
> Dale writes:
> 
>> I have a question on this.  I have a drive that I use for movies and
>> such.  There is nothing OS related on that drive.  Would it be safe to
>> set this to say 1% or even 0? 
> 
> I'd say 1% is okay. For 0% I'm not sure, I avoid that, but maybe there
> will be no noticeable difference at all. 
> 
>> Also, it is already set up with LVM and
>> ext4.  Can I change it even while there is data on there?
> 
> Sure! Cool, isn't it. Just call lvresize -L +1G /dev/mapper/whatever or
> something, and then resize2fs /dev/mapper/whatever.


I was talking about the command to change the superuser reserves.  I
know how to make LVM bigger but wanted to make sure this can be run even
when there is data on there.  Basically, can I run:

tune2fs -m 1 /dev/data/data1

Which is where the ext4 file system is on the LVM.  After I run that
then I can expand LVM from there, I hope it works that easy.


> 	Wonko
> 
> 

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] Freeing up disk space problem!!

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

On Tue, 28 Feb 2012 20:38:13 -0600, Dale wrote:

> tune2fs -m 1 /dev/data/data1
> 
> Which is where the ext4 file system is on the LVM.  After I run that
> then I can expand LVM from there, I hope it works that easy.

It does.


-- 
Neil Bothwick

The human mind ordinarily operates at only ten per cent of its
capacity ... the rest is overhead for the operating system.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Freeing up disk space problem!!

[Dale]

Neil Bothwick wrote:
> On Tue, 28 Feb 2012 20:38:13 -0600, Dale wrote:
> 
>> tune2fs -m 1 /dev/data/data1
>>
>> Which is where the ext4 file system is on the LVM.  After I run that
>> then I can expand LVM from there, I hope it works that easy.
> 
> It does.
> 
> 


Apparently I am missing something then.  I looked at cfdisk for the
drive. It reported  right at 750Gb as it should with the change.  Thing
is, I can't get anything else to add it or to even show it is available.
 Some results somewhat shortened:

From cfdisk

 750156.38Mb

root@fireball / # pvs
  PV         VG   Fmt  Attr PSize   PFree
  /dev/sdc1  data lvm2 a--  698.63g    0
root@fireball / # vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  data   1   1   0 wz--n- 698.63g    0
root@fireball / # lvs
  LV    VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  data1 data -wi-ao 698.63g
root@fireball / #


So, cfdisk is happy with the change but nothing else seems to see it.
What am I missing here?  Where did the 50Gbs go to?

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] Freeing up disk space problem!!

[J. Roeleveld]

On Wed, February 29, 2012 8:10 am, Dale wrote:
> Neil Bothwick wrote:
>> On Tue, 28 Feb 2012 20:38:13 -0600, Dale wrote:
>>
>>> tune2fs -m 1 /dev/data/data1
>>>
>>> Which is where the ext4 file system is on the LVM.  After I run that
>>> then I can expand LVM from there, I hope it works that easy.
>>
>> It does.
>>
>>
>
>
> Apparently I am missing something then.  I looked at cfdisk for the
> drive. It reported  right at 750Gb as it should with the change.  Thing
> is, I can't get anything else to add it or to even show it is available.
>  Some results somewhat shortened:
>
> From cfdisk
>
>  750156.38Mb
>
> root@fireball / # pvs
>   PV         VG   Fmt  Attr PSize   PFree
>   /dev/sdc1  data lvm2 a--  698.63g    0
> root@fireball / # vgs
>   VG   #PV #LV #SN Attr   VSize   VFree
>   data   1   1   0 wz--n- 698.63g    0
> root@fireball / # lvs
>   LV    VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
>   data1 data -wi-ao 698.63g
> root@fireball / #
>
>
> So, cfdisk is happy with the change but nothing else seems to see it.
> What am I missing here?  Where did the 50Gbs go to?
>
> Dale

What you're missing here is the fact that different tools report the sizes
differently.
Look into the difference between "GiB" and "GB":

http://en.wikipedia.org/wiki/Mebibyte

you have:
750156.38 MiB =
750156380 KiB =
750156380000 B =
732574589.8 KB =
715404.87 MB =
698.63 GB

(with the "i" the factor is 1000, without it, the factor is 1024)

HTH,

Joost

Re: [gentoo-user] Freeing up disk space problem!!

[Alan McKinnon]

On Wed, 29 Feb 2012 01:10:05 -0600
Dale <rdalek1967@gmail.com> wrote:

> Neil Bothwick wrote:
> > On Tue, 28 Feb 2012 20:38:13 -0600, Dale wrote:
> > 
> >> tune2fs -m 1 /dev/data/data1
> >>
> >> Which is where the ext4 file system is on the LVM.  After I run
> >> that then I can expand LVM from there, I hope it works that easy.
> > 
> > It does.
> > 
> > 
> 
> 
> Apparently I am missing something then.  I looked at cfdisk for the
> drive. It reported  right at 750Gb as it should with the change.
> Thing is, I can't get anything else to add it or to even show it is
> available. Some results somewhat shortened:
> 
> From cfdisk
> 
>  750156.38Mb
> 
> root@fireball / # pvs
>   PV         VG   Fmt  Attr PSize   PFree
>   /dev/sdc1  data lvm2 a--  698.63g    0
> root@fireball / # vgs
>   VG   #PV #LV #SN Attr   VSize   VFree
>   data   1   1   0 wz--n- 698.63g    0
> root@fireball / # lvs
>   LV    VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
>   data1 data -wi-ao 698.63g
> root@fireball / #
> 
> 
> So, cfdisk is happy with the change but nothing else seems to see it.
> What am I missing here?  Where did the 50Gbs go to?
> 
> Dale
> 
> :-)  :-)
> 

Nowhere.

Disk manufacturers measure kilos of data as 1000
Everyone else measures it in 1024

They do this because it fudges disk sizes to appear 2.4% bigger than
they really are. 

When you get into TB drives, it gets worse as 1024*1024*1024*1024
differs from 1000*1000*1000*1000 bu a lot more than 2.4%

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Freeing up disk space problem!!

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

On Wed, Feb 29, 2012 at 11:23:11AM +0200, Alan McKinnon wrote:

> > So, cfdisk is happy with the change but nothing else seems to see it.
> > What am I missing here?  Where did the 50Gbs go to?
> > 
> > Dale
> > 
> > :-)  :-)
> > 
> 
> Nowhere.
> 
> Disk manufacturers measure kilos of data as 1000
> Everyone else measures it in 1024

Well, to nitpick, they say it correctly, as for their "kilo", 10^3 bytes is
correct. We, the binary folk, assert kilo to be 2^10 bytes which is actually
called kibi, but we still use "kilo" in our everyday language thanks to
historical ballast (and because, as I recently heard, the -bi units aren't
around that long yet). First time I heard of them was in uni lecture ~2003±1.

> They do this because it fudges disk sizes to appear 2.4% bigger than
> they really are. 
> 
> When you get into TB drives, it gets worse as 1024*1024*1024*1024
> differs from 1000*1000*1000*1000 bu a lot more than 2.4%

By 1.024^4, which is 1.0995 to be precise. Those swines are stealing almost
10% from us. :o)
-- 
Gruß | Greetings | Qapla'
I forbid any use of my email addresses with Facebook services.

“Don't put multiple statements on a single line unless you have something
to hide.” – Linux Torvalds, Linux kernel coding style documentation

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Freeing up disk space problem!!

[Alan McKinnon]

On Thu, 1 Mar 2012 02:09:04 +0100
Frank Steinmetzger <Warp_7@gmx.de> wrote:

> > Disk manufacturers measure kilos of data as 1000
> > Everyone else measures it in 1024  
> 
> Well, to nitpick, they say it correctly, as for their "kilo", 10^3
> bytes is correct. We, the binary folk, assert kilo to be 2^10 bytes
> which is actually called kibi, but we still use "kilo" in our
> everyday language thanks to historical ballast (and because, as I
> recently heard, the -bi units aren't around that long yet). First
> time I heard of them was in uni lecture ~2003±1.

Yeah, I know the reasoning they use. But the entire world and everyone
in it intuitively expects disk capacity to be measured in units of 2^X

Especially as the disk manufacturers themselves make their disks to
have allocation unit like 512, 1024 and 4096 bytes, not 500, 1000 and
4000

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Freeing up disk space problem!!

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

On Wed, 29 Feb 2012 01:10:05 -0600, Dale wrote:

> >> tune2fs -m 1 /dev/data/data1
> >>
> >> Which is where the ext4 file system is on the LVM.  After I run that
> >> then I can expand LVM from there, I hope it works that easy.  
> > 
> > It does.

> Apparently I am missing something then.  I looked at cfdisk for the
> drive. It reported  right at 750Gb as it should with the change.  Thing
> is, I can't get anything else to add it or to even show it is available.

cfdisk deals with disk partitions, not filesystems. That's like buying
bigger socks and complaining that your shoes are still too tight.


-- 
Neil Bothwick

WITLAG: The delay between delivery and comprehension of a joke.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Freeing up disk space problem!!

[Alan McKinnon]

On Tue, 28 Feb 2012 20:38:13 -0600
Dale <rdalek1967@gmail.com> wrote:

> Alex Schuster wrote:
> > Dale writes:
> > 
> >> I have a question on this.  I have a drive that I use for movies
> >> and such.  There is nothing OS related on that drive.  Would it be
> >> safe to set this to say 1% or even 0? 
> > 
> > I'd say 1% is okay. For 0% I'm not sure, I avoid that, but maybe
> > there will be no noticeable difference at all. 
> > 
> >> Also, it is already set up with LVM and
> >> ext4.  Can I change it even while there is data on there?
> > 
> > Sure! Cool, isn't it. Just call lvresize -L
> > +1G /dev/mapper/whatever or something, and then
> > resize2fs /dev/mapper/whatever.
> 
> 
> I was talking about the command to change the superuser reserves.  I
> know how to make LVM bigger but wanted to make sure this can be run
> even when there is data on there.  Basically, can I run:
> 
> tune2fs -m 1 /dev/data/data1
> 
> Which is where the ext4 file system is on the LVM.  After I run that
> then I can expand LVM from there, I hope it works that easy.

They don't interfere with each other.

LVM and the size of the filesystem is one thing. Reserved space is
something else, completely unrelated.


> 
> 
> > 	Wonko
> > 
> > 
> 
> Dale
> 
> :-)  :-)
> 



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Freeing up disk space problem!!

[Dale]

Alan McKinnon wrote:

> They don't interfere with each other.
> 
> LVM and the size of the filesystem is one thing. Reserved space is
> something else, completely unrelated.
> 
> 


Ahhh, light bulb moment.  Gotcha !!

Dale

:-)  :-)


-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] Freeing up disk space problem!!

[J. Roeleveld]

On Wed, February 29, 2012 2:01 am, Alex Schuster wrote:
> Dale writes:
>
>> Alex Schuster wrote:
>>

<snipped>

>> Also, it is already set up with LVM and
>> ext4.  Can I change it even while there is data on there?
>
> Sure! Cool, isn't it. Just call lvresize -L +1G /dev/mapper/whatever or
> something, and then resize2fs /dev/mapper/whatever.

I don't use ext4 (yet), so not sure about this. But, isn't "resize2fs" for
ext2/3 only?

-- 
Joost

Re: [gentoo-user] Freeing up disk space problem!!

[Daddy]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]




On February 29, 2012 at 2:43 AM "J. Roeleveld" <joost@antarean.org> wrote:

>
> On Wed, February 29, 2012 2:01 am, Alex Schuster wrote:
> > Dale writes:
> >
> >> Alex Schuster wrote:
> >>
>
> <snipped>
>
> >> Also, it is already set up with LVM and
> >> ext4.  Can I change it even while there is data on there?
> >
> > Sure! Cool, isn't it. Just call lvresize -L +1G /dev/mapper/whatever or
> > something, and then resize2fs /dev/mapper/whatever.
>
> I don't use ext4 (yet), so not sure about this. But, isn't "resize2fs"
for
> ext2/3 only?
>
> --
> Joost



From the man page:




On February 29, 2012 at 2:43 AM "J. Roeleveld" <joost@antarean.org> wrote:

>
> On Wed, February 29, 2012 2:01 am, Alex Schuster wrote:
> > Dale writes:
> >
> >> Alex Schuster wrote:
> >>
>
> <snipped>
>
> >> Also, it is already set up with LVM and
> >> ext4.  Can I change it even while there is data on there?
> >
> > Sure! Cool, isn't it. Just call lvresize -L +1G /dev/mapper/whatever or
> > something, and then resize2fs /dev/mapper/whatever.
>
> I don't use ext4 (yet), so not sure about this. But, isn't "resize2fs"
for
> ext2/3 only?
>
> --
> Joost



From the man page:

The resize2fs program will resize ext2, ext3, or ext4 file systems.

[-- Attachment #2: Type: text/html, Size: 3026 bytes --]

Re: [gentoo-user] Freeing up disk space problem!!

[Dale]

J. Roeleveld wrote:
> 
> On Wed, February 29, 2012 2:01 am, Alex Schuster wrote:
>> Dale writes:
>>
>>> Alex Schuster wrote:
>>>
> 
> <snipped>
> 
>>> Also, it is already set up with LVM and
>>> ext4.  Can I change it even while there is data on there?
>>
>> Sure! Cool, isn't it. Just call lvresize -L +1G /dev/mapper/whatever or
>> something, and then resize2fs /dev/mapper/whatever.
> 
> I don't use ext4 (yet), so not sure about this. But, isn't "resize2fs" for
> ext2/3 only?
> 


It works for ext4 too.  At least I been using it so I hope it is the
right tool.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] Freeing up disk space problem!!

[James Broadhead]

On 28 February 2012 11:37, trevor donahue <donahue.trevor@gmail.com> wrote:
> In situations like this I start deleting
> /var/tmp/*, /tmp/*, /usr/portage/distfiles/*, maybe do even a revdep-rebuild
> to fix something, but even then I'm left with no more then 100 mb, which
> obviously is not enough ...

Lots of good advice already, but I thought that I'd chime in to
suggest that you use `eclean` to free up space in distfiles, but only
removing downloaded files which aren't going to be used again. This
means that you don't need to re-download if you re-merge, and lightens
server load.

Another obvious suggestion: unless you're on a very constrained
system, consider re-partitioning to give yourself more root space -- I
very happily ran gentoo inside ~7 GiB for a very long time without
needing to shuffle things about. I recently bought one of these and a
16GiB SD card to quickly add space to my HTPC without disassembly (and
warranty-voiding).
http://www.dealextreme.com/p/kawau-world-s-smallest-microsd-transflash-tf-sd-sdhc-usb-2-0-card-reader-keychain-25558