Mailing List Archive

1 2  View All
Re: Freeing up disk space problem!! [ In reply to ]
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.
Re: Freeing up disk space problem!! [ In reply to ]
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!
Re: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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.
Re: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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.
Re: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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: Re: Freeing up disk space problem!! [ In reply to ]
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,
Re: Freeing up disk space problem!! [ In reply to ]
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
Re: Freeing up disk space problem!! [ In reply to ]
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
Re: Freeing up disk space problem!! [ In reply to ]
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: Freeing up disk space problem!! [ In reply to ]
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.

1 2  View All