All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sanders <linux@sandersweb.net>
To: Anton Altaparmakov <aia21@cam.ac.uk>
Cc: linux-kernel@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net
Subject: Re: [PATCH-BK-2.6] NTFS fix "du" and "stat" output (NTFS 2.1.6).
Date: Thu, 22 Jan 2004 12:48:20 -0500	[thread overview]
Message-ID: <200401221241.44393@sandersweb.net> (raw)
In-Reply-To: <1074763252.16782.25.camel@imp.csi.cam.ac.uk>

On Thursday 22 January 2004 04:20 am, you wrote:
> On Wed, 2004-01-21 at 18:24, David Sanders wrote:
> > On Monday 19 January 2004 09:15 am, Anton Altaparmakov wrote:
> > > This fixes the erroneous "du" and "stat" output people reported
> > > on ntfs partitions containing compressed directories.
> >
> > Thanks for the quick patch.  There are still problems with the
> > reported disk usage.
>
> No there are not.  It is a feature, not a bug.  (-:  I will explain
> below...
>
> > I use as an example the file win.ini.  With the 2.4.24
> > kernel I get the following results:
> > $ ls -l win.ini
> > -r--r-----    1 root     staff         399 Jan 27  2003 win.ini
> >
> > $ stat win.ini
> >   File: "win.ini"
> >   Size: 399       	Blocks: 2          IO Block: 1024   Regular File
> > Device: 305h/773d	Inode: 1023        Links: 1
> > Access: (0440/-r--r-----)  Uid: (    0/    root)   Gid: (   50/  
> > staff) Access: Thu Jan 15 15:34:09 2004
> > Modify: Mon Jan 27 18:54:00 2003
> > Change: Sun Sep 22 07:23:44 2002
> >
> > $ du -h win.ini
> > 1.0k	win.ini
>
> This is wrong.  The file size is 399 bytes,  and knowing from my own
> systems, win.ini is a resident file (which is consistent with the
> small size).  This means the file doesn't occupy any disk blocks at
> all.  All the data is stored inside the on-disk inode itself (that is
> the MFT record in NTFS speak).
>
> Further, the table of inodes (the system file $MFT) already has its
> own size (do "ls -l \$MFT" or "du \$MFT" in the main NTFS directory
> and you will see it together with its size).
>
> The size of the inode itself (1024 bytes) is already accounted for in
> the size of the $MFT system file (the table of inodes).
>
> Since the 399 bytes of win.ini are part of those 1024 bytes we would
> be counting them twice if we were to give them in the "Blocks:" field
> of stat, which is what "du" uses to calculate sizes.
>
> So by returning the above "Blocks: 2", the old NTFS driver (which is
> what you used by using an unpatched 2.4.24 kernel), du will actually
> tell you that you are using more space than you are as it would count
> 2 Blocks from win.ini and then the same 2 Blocks from $MFT which
> clearly
>
> is silly.  (-:
> > But, under the 2.6.1 kernel:
> > $ ls -l win.ini
> > -r-xr-x---    1 root     staff         399 Jan 27  2003 win.ini
> >
> > $ stat win.ini
> >   File: "win.ini"
> >   Size: 399       	Blocks: 0          IO Block: 4096   Regular File
> > Device: 305h/773d	Inode: 1023        Links: 1
> > Access: (0550/-r-xr-x---)  Uid: (    0/    root)   Gid: (   50/  
> > staff) Access: Thu Jan 15 15:34:09 2004
> > Modify: Mon Jan 27 18:54:00 2003
> > Change: Mon Jan 27 18:54:00 2003
>
> Correct.  No disk blocks are occupied as explained above.
>
> > $ du -h win.ini
> > 0	win.ini
>
> That is correct.  To quote from the man page for "du":
>
> 	"Summarize disk usage of each FILE"
>
> It is "disk usage" not "file size" and the file "win.ini" does not
> use any disk space as explained above.
>
> > Now, surely the 2.4.24 kernel is reporting the more accurate disk
> > usage since with 2.6.1 it reports 0 blocks (vice 2).
>
> Nope.  Sometimes things are not what they seem.  (-:
>
> Hope this clears the confusion up.
>
> Best regards,
>
> 	Anton
Yes, I think that clears it up in my mind, but I think the output of du 
is a little misleading to the uninitiated.

Thanks, David
-- 
David Sanders
linux@sandersweb.net

      reply	other threads:[~2004-01-22 17:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-19 14:15 [PATCH-BK-2.6] NTFS fix "du" and "stat" output (NTFS 2.1.6) Anton Altaparmakov
2004-01-21 18:24 ` David Sanders
2004-01-21 19:14   ` David Sanders
2004-01-22  9:29     ` Anton Altaparmakov
2004-01-21 19:38   ` David Sanders
2004-01-22 10:32     ` Anton Altaparmakov
2004-01-22  9:20   ` Anton Altaparmakov
2004-01-22 17:48     ` David Sanders [this message]

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=200401221241.44393@sandersweb.net \
    --to=linux@sandersweb.net \
    --cc=aia21@cam.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntfs-dev@lists.sourceforge.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.