mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Abraham vd Merwe <abraham@2d3d.co.za>
To: Linux Kernel Development <linux-kernel@vger.kernel.org>
Cc: Allen Van Der Ross <allen@ct.spi.co.za>
Subject: Fwd: [allen@ct.spi.co.za: Re: [CLUG-tech] statfs()  vs. df]
Date: Tue, 23 Jul 2002 12:22:44 +0200	[thread overview]
Message-ID: <20020723122244.A3839@crystal.2d3d.co.za> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 1665 bytes --]

Hi!

Can anyone explain this? He's got 2.4.2 with libc6 2.2.x. df -k returns the
correct results for his partition. Both statfs() and statvfs() returns bogus
values. From his last email it looks like it's actually returning stats for
/dev/hda8 instead of /dev/hda9.

Is this a (known) bug?

Here is the source for the program mentioned in the email:

------------< snip <------< snip <------< snip <------------
root@crystal:~# cat /tmp/t.c

#include <stdio.h>
#include <sys/vfs.h>
#include <sys/statvfs.h>

static const char part[] = "/dev/hda9";

int main ()
{
        struct statfs stat;
        struct statvfs vfs;

        if (statfs (part,&stat) < 0) {
                perror ("statfs");
                return(1);
        }
        printf("f_blocks: %ld, f_bsize: %d\n",stat.f_blocks,stat.f_bsize);

        if (statvfs (part,&vfs) < 0) {
                perror ("statvfs");
                return(1);
        }
        printf("f_bsize: %lu, f_blocks: %lu\n",vfs.f_bsize,vfs.f_blocks);

        return(0);
}

------------< snip <------< snip <------< snip <------------

-- 

Regards
 Abraham

Avoid Quiet and Placid persons unless you are in Need of Sleep.
		-- National Lampoon, "Deteriorata"

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Aintree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #1.2: Type: message/rfc822, Size: 5077 bytes --]

From: "Allen Van Der Ross" <allen@ct.spi.co.za>
To: <clug-tech@clug.org.za>
Subject: Re: [CLUG-tech] statfs()  vs. df
Date: Tue, 23 Jul 2002 12:00:16 +0200
Message-ID: <01bb01c2322f$c1591e10$1e210a0a@spi.co.za>

> allen@eagle:~$ uname -a
> Linux eagle.spi.co.za 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown

I just had a look at the source for the df from fileutils 4.0.37 and it can
get the filesystem stats in a number of ways

1. statfs()
2. reading a filsys structure directly from the superblock of the
filesystem.
3. statvfs()

I've modified my test program to display both. See if you get different
output. Also try compiling the program with -D_LARGEFILE64_SOURCE and see if
that makes a difference (shouldn't since your partition is quite small).

<
< I have also played with options 1 and 3, using statfs() and statvfs()
which
< both display the same information.
< Compiling t.c with -D_LARGEFILE64_SOURCE doesn't make a differance
< as you thought. I was hoping not to get involved with option 2 for now,
< since time does not permit and I'm on the verge of execing("df -k").

(Which reminds me. How big is your partition really? I take it df gave the
correct output which makes it a 2.8G partition?)

< Yep, its quite small. I have to re-install this machine this weekend and
that's
< one of the things I need to fix. :)

Also, what filesystem do you have on there?

< ext2fs is all I use on this machine.

If this is the same I give up. In that case I suggest you grab a copy of the
latest fileutils, compile it with debugging and run df through the debugger.
(break on get_fs_usage and step through the function to see what method it
uses on your system).

< yes it is the same. I will check out fileutils.
< yet I saw something very interesting...hmmm....
< don't understand it, but all the programs (we) wrote
< did return valid values, but for / (root) partition, which
< is on /dev/hda8 (even tho I explicitly tested with /dev/hda9)
< see this:

gcc t.c  (your latest t.c)
allen@eagle:~$ ./a.out
f_blocks: 350021, f_bsize: 1024
f_bsize: 1024, f_blocks: 350021

allen@eagle:~$ ./fs /dev/hda
/dev/hda:       total blocks 350021     free blocks 217464

allen@eagle:~$ ./fs /dev/hda9
/dev/hda9:      total blocks 350021     free blocks 217458

allen@eagle:~$ df -k
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda8               350021    132578    199372  40% /
/dev/hda9              3028080   2575624    298636  90% /usr
...

What can you make of it?

-Allen


-- 
Clug-tech mailing list
Clug-tech@clug.org.za
To (un)subscribe:
http://www2.clug.org.za/mailman/listinfo/clug-tech

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

                 reply	other threads:[~2002-07-23 10:17 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020723122244.A3839@crystal.2d3d.co.za \
    --to=abraham@2d3d.co.za \
    --cc=allen@ct.spi.co.za \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®