Mailing List Archive

Freeing up disk space problem!!
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?
Re: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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
Re: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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?
>
>
Re: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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..
Re: Freeing up disk space problem!! [ In reply to ]
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.
Re: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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
Re: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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.
Re: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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.
Re: Freeing up disk space problem!! [ In reply to ]
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!
Re: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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

1 2  View All