2:05 p.m.
Hi
I just came across this issue on my server at home which complained
about the lack of space which I knew was wrong. It was supposed to
have atleast 3.5 gig free. On investigating I found that there a few
lines showing the following behaviour.
Running du -h tells that the file occupies 512M but ls -l tells that
the file is a lot smaller. Also I am sure the the cluster size is not
512M (or am I wrong there?).
I have provided the relevant information from fstab, du, ls and uname
and if more info is needed, I can provide that too. But is there a
solution to this problem?
Vijay
/dev/sda2 / xfs
noatime,nodiratime,async,allocsize=1M,noikeep 0 0
[root@aria ~]# du -sh /var/log/httpd/* | grep M
512M /var/log/httpd/webserver-access_log
[root@aria ~]# ls -l /var/log/httpd/webserver-access_log
-rw-r--r-- 1 root root 2884214 2009-02-15 16:18
/var/log/httpd/webserver-access_log
[root@aria ~]# xfs_info /dev/sda2
meta-data=/dev/root isize=256 agcount=4, agsize=524121 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=2096482, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0
[root@aria ~]# uname -a
Linux aria 2.6.27.12-170.2.5.fc10.i686 #1 SMP Wed Jan 21 02:09:37 EST
2009 i686 athlon i386 GNU/Linux
5:55 p.m.
On Fri, 2009-02-20 at 13:15 -0800, Leslie Satenstein wrote:
--- On Mon, 2/16/09, Patrick O'Callaghan <pocallaghan(a)gmail.com>
wrote:
From: Patrick O'Callaghan <pocallaghan(a)gmail.com>
Subject: Re: Can somebody explain this? du & ls showing
different sizes
To: fedora-list(a)redhat.com
Date: Monday, February 16, 2009, 8:45 AM
On Mon, 2009-02-16 at 07:13 +0000, Vijay Gill wrote:
> 2009/2/16 Patrick O'Callaghan <pocallaghan(a)gmail.com>:
> > On Sun, 2009-02-15 at 23:45 +0000, Vijay Gill wrote:
> >> > That could be because you're using XFS.
> >> >
> >> > poc
> > [...]
> >> Thanks but how does that statement explain the behaviour I am
seeing?
> >
> > I'm
reaching here, but since XFS uses allocation strategies
different
> > from the more familiar ext3 system, I wondered if 'du' could
in some
> > circumstances report larger numbers than "normal".
> >
> > Apologies if I'm raving.
> >
> > poc
> >
> > --
> > fedora-list mailing list
> > fedora-list(a)redhat.com
> > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
> > Guidelines:
http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
> >
>
> You are spot on Pat. XFS allws you to pre-allocate contiguous area of
> disk for a file when it is opened for writing data. This is determined
> by allocsize parameter during mount and is used foe reducing
> fragmentation(fragmentation in Linux? yes siree, it does happen in
> Linux too).
>
> In my case I have provided 1M
which is far much less than 512M which
> XFS is pre-allocating. This is what caught my eye.
It's nice to have one's intuition confirmed once in a while :-)
poc
Hi Poc
Where is the overallocation parameter stored?
Poc, I appreciate your expertise in the answers, but when you answer something
about Linux,
note that I have not your ideas of where to look for settings.
Therefore, I am sure readers would like a hint about the directory/file in which
this info
is stored.
Thanks and have a good weekend.
Leslie
Actually I don't claim any specific expertise regarding XFS, but when
you mess about with operating systems and filesystems for many many
years, you develop a certain feeling for how things are likely to work
(there's nothing new under the sun). As to where XFS stores the
"overallocation parameter", I've no idea but the first place I'd look
would be in the filesystem superblock, not in any file or directory.
Or as a last resort you could always read the manual ...
poc
PS Please don't post in HTML. I can't edit it sensibly, which is why I
just tacked a reply on the end. It's also contrary to the Guidelines of
this list.
4:21 p.m.
Latest kernel (kernel-2.6.27.12-170.2.5.fc10.i686): files under
/var/log, /var/run and even MySQL database files get 512M allocated to
them while they are open (which they do while system is running) even
though their size is very small, leading to reporting of very less
free space(a few megabytes) even though 3.1G should be reported.
Previous Kernel (2.6.27.9-159.fc10.i686): There is no such behaviour
and system reports correct free space.
I will file bug in bugzilla this week-end after collecting more
information instead of just some observations.
I read the mail of that guy and you are right, he was talking of FC7.
Vijay
4:09 p.m.
On Wed, 2009-02-18 at 18:12 +0000, Vijay Gill wrote:
> What do you mean "the problem went away"? Do you mean
that the 512M
> files created under the new kernel now showed only a few bytes
> allocated, or do you mean that *new* files created under the *old*
> kernel don't have the 512M allocation?
>
> poc
>
> PS Your mailer is including the entire trailer of list messages in the
> quoted material. This is dumb and most mailers don't do it. You should
> either edit it out or consider using a different mailer.
>
By 'the problem went away' I meant that the files were no getting 512M
allocated for them even if they were a few bytes in size.
Allocated *under which kernel*? You still haven't said. If this is a
genuine bug you should report it to Bugzilla, but it's essential to be
clear about what's happening.
The trouble it was causing is explained in following text.
The files in question were in /var/log and /var/run. Most of them were
very small (ranging from 5-6 bytes to a few kilo bytes). But XFS
pre-allocated 512M to them. Once XFS pre-allocates space to a file,
the free space reported decreases by the amount that is pre-allocated
and not by the actual data written into the file. If these files are
closed then XFS would report free space left correctly. Since these
files were always open, my hard disk showed only a few megabytes free
even though it was supposed to have 3.1Gb free (as reported now).
I have a suspicion that there is another linux user facing similar
problem (he also ran out of space in /var as he said). He might be
running the latest kernel.
If I remember correctly, he was talking about installing (or
reinstalling) an old system, something like FC7.
As far as my mailer is concerned I am using gmail (web interface). I
try to truncate the text as much as possible and keep text from only
previous mail so that the context is clear. It is as dumb as it is I
cannot help there.
Well this time you did remove the trailing material, so that's fine.
poc
12:12 p.m.
What do you mean "the problem went away"? Do you mean that
the 512M
files created under the new kernel now showed only a few bytes
allocated, or do you mean that *new* files created under the *old*
kernel don't have the 512M allocation?
poc
PS Your mailer is including the entire trailer of list messages in the
quoted material. This is dumb and most mailers don't do it. You should
either edit it out or consider using a different mailer.
By 'the problem went away' I meant that the files were no getting 512M
allocated for them even if they were a few bytes in size.
The trouble it was causing is explained in following text.
The files in question were in /var/log and /var/run. Most of them were
very small (ranging from 5-6 bytes to a few kilo bytes). But XFS
pre-allocated 512M to them. Once XFS pre-allocates space to a file,
the free space reported decreases by the amount that is pre-allocated
and not by the actual data written into the file. If these files are
closed then XFS would report free space left correctly. Since these
files were always open, my hard disk showed only a few megabytes free
even though it was supposed to have 3.1Gb free (as reported now).
I have a suspicion that there is another linux user facing similar
problem (he also ran out of space in /var as he said). He might be
running the latest kernel.
As far as my mailer is concerned I am using gmail (web interface). I
try to truncate the text as much as possible and keep text from only
previous mail so that the context is clear. It is as dumb as it is I
cannot help there.
I hope I have explained things properly.
Vijay
6:11 a.m.
On Tue, 2009-02-17 at 23:29 +0000, Vijay Gill wrote:
2009/2/17 Patrick O'Callaghan <pocallaghan(a)gmail.com>:
> On Tue, 2009-02-17 at 23:05 +0000, Vijay Gill wrote:
>> Back again with another observation.
>>
>> I found out that this issue happens only with
>> kernel-2.6.27.12-170.2.5.fc10.i686 (the latest one I have). I had a
>> previous kernel too (kernel-2.6.27.9-159.fc10.i686) and there is no
>> problem with that. I tried compare the change log of the two rpms and
>> there seemed nothing about changes to XFS.
>
> Does it make a difference which of the two kernels creates the file?
[...]
Well most of the files which exihibit that issue were in /var/run or
/var/log. While investigating the latest kernel I had even cleared
/var/run still the files created were a few bytes in size but were
allocated 512M. I did nothing except rebooting to old kernel and
problem went away.
What do you mean "the problem went away"? Do you mean that the 512M
files created under the new kernel now showed only a few bytes
allocated, or do you mean that *new* files created under the *old*
kernel don't have the 512M allocation?
poc
PS Your mailer is including the entire trailer of list messages in the
quoted material. This is dumb and most mailers don't do it. You should
either edit it out or consider using a different mailer.
5:29 p.m.
2009/2/17 Patrick O'Callaghan <pocallaghan(a)gmail.com>:
On Tue, 2009-02-17 at 23:05 +0000, Vijay Gill wrote:
> Back again with another observation.
>
> I found out that this issue happens only with
> kernel-2.6.27.12-170.2.5.fc10.i686 (the latest one I have). I had a
> previous kernel too (kernel-2.6.27.9-159.fc10.i686) and there is no
> problem with that. I tried compare the change log of the two rpms and
> there seemed nothing about changes to XFS.
Does it make a difference which of the two kernels creates the file?
poc
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Well most of the files which exihibit that issue were in /var/run or
/var/log. While investigating the latest kernel I had even cleared
/var/run still the files created were a few bytes in size but were
allocated 512M. I did nothing except rebooting to old kernel and
problem went away. My server is running the same services as in the
case when the latest kernel was used.
So it seems that there is a difference in creation of files by the teo kernels.
Vijay
5:09 p.m.
On Tue, 2009-02-17 at 23:05 +0000, Vijay Gill wrote:
Back again with another observation.
I found out that this issue happens only with
kernel-2.6.27.12-170.2.5.fc10.i686 (the latest one I have). I had a
previous kernel too (kernel-2.6.27.9-159.fc10.i686) and there is no
problem with that. I tried compare the change log of the two rpms and
there seemed nothing about changes to XFS.
Does it make a difference which of the two kernels creates the file?
poc
7:45 a.m.
On Mon, 2009-02-16 at 07:13 +0000, Vijay Gill wrote:
2009/2/16 Patrick O'Callaghan <pocallaghan(a)gmail.com>:
> On Sun, 2009-02-15 at 23:45 +0000, Vijay Gill wrote:
>> > That could be because you're using XFS.
>> >
>> > poc
> [...]
>> Thanks but how does that statement explain the behaviour I am seeing?
>
> I'm reaching here, but since XFS uses allocation strategies different
> from the more familiar ext3 system, I wondered if 'du' could in some
> circumstances report larger numbers than "normal".
>
> Apologies if I'm raving.
>
> poc
>
> --
> fedora-list mailing list
> fedora-list(a)redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
> Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
>
You are spot on Pat. XFS allws you to pre-allocate contiguous area of
disk for a file when it is opened for writing data. This is determined
by allocsize parameter during mount and is used foe reducing
fragmentation(fragmentation in Linux? yes siree, it does happen in
Linux too).
In my case I have provided 1M which is far much less than 512M which
XFS is pre-allocating. This is what caught my eye.
It's nice to have one's intuition confirmed once in a while :-)
poc
1:13 a.m.
2009/2/16 Patrick O'Callaghan <pocallaghan(a)gmail.com>:
On Sun, 2009-02-15 at 23:45 +0000, Vijay Gill wrote:
> > That could be because you're using XFS.
> >
> > poc
[...]
> Thanks but how does that statement explain the behaviour I am seeing?
I'm reaching here, but since XFS uses allocation strategies different
from the more familiar ext3 system, I wondered if 'du' could in some
circumstances report larger numbers than "normal".
Apologies if I'm raving.
poc
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
You are spot on Pat. XFS allws you to pre-allocate contiguous area of
disk for a file when it is opened for writing data. This is determined
by allocsize parameter during mount and is used foe reducing
fragmentation(fragmentation in Linux? yes siree, it does happen in
Linux too).
In my case I have provided 1M which is far much less than 512M which
XFS is pre-allocating. This is what caught my eye.
Cheers
Vijay
5:11 p.m.
2009/2/15 Rick <ellis(a)spinics.net>:
In article
<60fdb1ad0902151205v6ef67c07v128f0c88f5895240(a)mail.gmail.com>,
Vijay Gill <fedora-list(a)redhat.com> wrote:
>Running du -h tells that the file occupies 512M but ls -l tells that
>the file is a lot smaller.
Apples and oranges. You get the file *size* with ls and the disk usage
with du. They aren't the same thing.
--
http://yosemitenews.info/
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Thanks but I knew that already. I was just curious why 512Mbytes is
allocated to a file so small? Also I have provided allocsize which is
definitely not 512M!
3:56 p.m.
In article <60fdb1ad0902151205v6ef67c07v128f0c88f5895240(a)mail.gmail.com>,
Vijay Gill <fedora-list(a)redhat.com> wrote:
Running du -h tells that the file occupies 512M but ls -l tells that
the file is a lot smaller.
Apples and oranges. You get the file *size* with ls and the disk usage
with du. They aren't the same thing.
--
http://yosemitenews.info/
5:45 p.m.
2009/2/15 Patrick O'Callaghan <pocallaghan(a)gmail.com>:
On Sun, 2009-02-15 at 23:11 +0000, Vijay Gill wrote:
> 2009/2/15 Rick <ellis(a)spinics.net>:
> > In article <60fdb1ad0902151205v6ef67c07v128f0c88f5895240(a)mail.gmail.com>,
> > Vijay Gill <fedora-list(a)redhat.com> wrote:
> >
> >>Running du -h tells that the file occupies 512M but ls -l tells that
> >>the file is a lot smaller.
> >
> > Apples and oranges. You get the file *size* with ls and the disk usage
> > with du. They aren't the same thing.
> >
> > --
> > http://yosemitenews.info/
> >
> > --
> > fedora-list mailing list
> > fedora-list(a)redhat.com
> > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
> > Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
> >
>
> Thanks but I knew that already. I was just curious why 512Mbytes is
> allocated to a file so small? Also I have provided allocsize which is
> definitely not 512M!
That could be because you're using XFS.
poc
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Thanks but how does that statement explain the behaviour I am seeing?
5:30 p.m.
On Sun, 2009-02-15 at 23:11 +0000, Vijay Gill wrote:
2009/2/15 Rick <ellis(a)spinics.net>:
> In article <60fdb1ad0902151205v6ef67c07v128f0c88f5895240(a)mail.gmail.com>,
> Vijay Gill <fedora-list(a)redhat.com> wrote:
>
>>Running du -h tells that the file occupies 512M but ls -l tells that
>>the file is a lot smaller.
>
> Apples and oranges. You get the file *size* with ls and the disk usage
> with du. They aren't the same thing.
>
> --
> http://yosemitenews.info/
>
> --
> fedora-list mailing list
> fedora-list(a)redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
> Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
>
Thanks but I knew that already. I was just curious why 512Mbytes is
allocated to a file so small? Also I have provided allocsize which is
definitely not 512M!
That could be because you're using XFS.
poc
5:16 p.m.
2009/2/15 Vijay Gill <vijay.s.gill(a)gmail.com>:
2009/2/15 Rick <ellis(a)spinics.net>:
> In article <60fdb1ad0902151205v6ef67c07v128f0c88f5895240(a)mail.gmail.com>,
> Vijay Gill <fedora-list(a)redhat.com> wrote:
>
>>Running du -h tells that the file occupies 512M but ls -l tells that
>>the file is a lot smaller.
>
> Apples and oranges. You get the file *size* with ls and the disk usage
> with du. They aren't the same thing.
>
> --
> http://yosemitenews.info/
>
I found another funny behavior. Notice the sizes of
/var/log/samba/log.winbindd-idmap before and after I run xfs_io -c
stats on it. Again just looking at stats must not change the space
allocated to the file.
[root@aria tmp]# du -sh /var/log/samba/*
0 /var/log/samba/asus.log
0 /var/log/samba/cores
12K /var/log/samba/__ffff_10.1.0.151.log
52K /var/log/samba/log.nmbd
4.0K /var/log/samba/log.smbd
0 /var/log/samba/log.wb-ARIA
0 /var/log/samba/log.wb-BUILTIN
4.0K /var/log/samba/log.winbindd
0 /var/log/samba/log.winbindd-dc-connect
512M /var/log/samba/log.winbindd-idmap
56K /var/log/samba/log.winbindd-idmap.old
512M /var/log/samba/nmbd.log
4.0K /var/log/samba/smbd.log
4.0K /var/log/samba/winbindd.log
[root@aria tmp]# xfs_io -c stat /var/log/samba/log.winbindd-idmap
fd.path = "/var/log/samba/log.winbindd-idmap"
fd.flags = non-sync,non-direct,read-write
stat.ino = 3944597
stat.type = regular file
stat.size = 403
stat.blocks = 1048576
fsxattr.xflags = 0x0 [--------------]
fsxattr.projid = 0
fsxattr.extsize = 0
fsxattr.nextents = 2
fsxattr.naextents = 0
dioattr.mem = 0x200
dioattr.miniosz = 512
dioattr.maxiosz = 2147483136
[root@aria tmp]# du -sh /var/log/samba/*
0 /var/log/samba/asus.log
0 /var/log/samba/cores
12K /var/log/samba/__ffff_10.1.0.151.log
52K /var/log/samba/log.nmbd
4.0K /var/log/samba/log.smbd
0 /var/log/samba/log.wb-ARIA
0 /var/log/samba/log.wb-BUILTIN
4.0K /var/log/samba/log.winbindd
0 /var/log/samba/log.winbindd-dc-connect
4.0K /var/log/samba/log.winbindd-idmap
56K /var/log/samba/log.winbindd-idmap.old
512M /var/log/samba/nmbd.log
4.0K /var/log/samba/smbd.log
4.0K /var/log/samba/winbindd.log
[root@aria tmp]#
5:05 p.m.
Back again with another observation.
I found out that this issue happens only with
kernel-2.6.27.12-170.2.5.fc10.i686 (the latest one I have). I had a
previous kernel too (kernel-2.6.27.9-159.fc10.i686) and there is no
problem with that. I tried compare the change log of the two rpms and
there seemed nothing about changes to XFS.
Vijay
8:32 p.m.
On Sun, 2009-02-15 at 23:45 +0000, Vijay Gill wrote:
> That could be because you're using XFS.
>
> poc
[...]
Thanks but how does that statement explain the behaviour I am seeing?
I'm reaching here, but since XFS uses allocation strategies different
from the more familiar ext3 system, I wondered if 'du' could in some
circumstances report larger numbers than "normal".
Apologies if I'm raving.
poc
3:15 p.m.
--- On Mon, 2/16/09, Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
From: Patrick O'Callaghan <pocallaghan(a)gmail.com>
Subject: Re: Can somebody explain this? du & ls showing different sizes
To: fedora-list(a)redhat.com
Date: Monday, February 16, 2009, 8:45 AM
On Mon, 2009-02-16 at 07:13 +0000, Vijay Gill wrote:
2009/2/16 Patrick O'Callaghan <pocallaghan(a)gmail.com>:
> On Sun, 2009-02-15 at 23:45 +0000, Vijay Gill wrote:
>> > That could be because you're using XFS.
>> >
>> > poc
> [...]
>> Thanks but how does that statement explain the behaviour I am
seeing?
>
> I'm reaching here, but since XFS uses allocation strategies
different
> from the more familiar ext3 system, I wondered if 'du'
could
in some
> circumstances report larger numbers than "normal".
>
> Apologies if I'm raving.
>
> poc
>
> --
> fedora-list mailing list
> fedora-list(a)redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
> Guidelines:
http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
>
You are spot on Pat. XFS allws you to pre-allocate contiguous area of
disk for a file when it is opened for writing data. This is determined
by allocsize parameter during mount and is used foe reducing
fragmentation(fragmentation in Linux? yes siree, it does happen in
Linux too).
In my case I have provided 1M which is far much less than 512M which
XFS is pre-allocating. This is what caught my eye.
It's nice to have one's intuition confirmed once in a while :-)
poc
Hi Poc
Where is the overallocation parameter stored?
Poc, I appreciate your expertise in the answers, but when you answer something about
Linux,
note that I have not your ideas of where to look for settings.
Therefore, I am sure readers would like a hint about the directory/file in which this
info
is stored.
Thanks and have a good weekend.
Leslie
5550
days inactive
5555
days old
18 comments
5 participants
participants (5)
-
Bill Crawford -
ellis＠spinics.net -
Leslie S Satenstein -
Patrick O'Callaghan -
Vijay Gill