linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anton Altaparmakov <aia21@cam.ac.uk>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Takashi Sato <sho@bsd.tnes.nec.co.jp>,
	Dave Kleikamp <shaggy@austin.ibm.com>,
	'Andreas Dilger' <adilger@clusterfs.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: stat64 for over 2TB file returned invalid st_blocks
Date: Thu, 08 Dec 2005 14:50:46 +0000	[thread overview]
Message-ID: <1134053446.17436.51.camel@imp.csi.cam.ac.uk> (raw)
In-Reply-To: <1134052043.7998.26.camel@lade.trondhjem.org>

On Thu, 2005-12-08 at 09:27 -0500, Trond Myklebust wrote:
> On Thu, 2005-12-08 at 20:38 +0900, Takashi Sato wrote:
> 
> > I prefer sector_t for i_blocks rather than newly defined blkcnt_t.
> > The reasons are:
> > 
> >   - Both i_blocks and common sector_t are for on-disk 512-byte unit.
> >     In this point of view, they have the same character.
> 
> One is a count of the number of blocks used by a file, and exists only
> in order to help filesystems cache this value. The other is a handle to
> a block. How is that the same?
> 
> >   - If we created the type blkcnt_t newly, the patch would have to
> >     touch a lot of files as follows, like sector_t does.
> >         block/Kconfig, asm-i386/types.h, asm-x86_64/types.h,
> >         asm-ppc/types.h, asm-s390/types.h, asm-sh/types.h,
> >         asm-h8300/types.h, asm-mips/types.h
> >     It will be simple if we use sector_t for i_blocks.
> 
> That is not a particularly good reason.
> 
> > Also, I cannot imagine the situation that > 2TB files are used over
> > network with CONFIG_LBD disabled kernel.  Is there such a thing
> > realistically?
> 
> Apart from this and the kstat wart, there is no reason to set CONFIG_LBD
> for a networked filesystem. Why would you want to buy a > 2TB local disk
> on an HPC cluster node if you already have a server?
> 
> I suppose we can make NFS use a private field instead, and just set
> i_blocks to 0, but that's unnecessarily wasteful too.

And it breaks applications, too (e.g. du will then report all your files
to be zero size)...

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

  reply	other threads:[~2005-12-08 14:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-06 12:42 stat64 for over 2TB file returned invalid st_blocks Takashi Sato
2005-12-06 14:30 ` Dave Kleikamp
2005-12-06 14:48   ` Trond Myklebust
2005-12-06 14:51     ` Dave Kleikamp
2005-12-06 21:24     ` Andreas Dilger
2005-12-07  0:59       ` Trond Myklebust
2005-12-07 10:57       ` Takashi Sato
2005-12-07 13:52         ` Trond Myklebust
2005-12-07 15:01           ` Dave Kleikamp
2005-12-07 15:34             ` Trond Myklebust
2005-12-07 16:34               ` Dave Kleikamp
2005-12-07 18:55                 ` Trond Myklebust
2005-12-08 11:38                 ` Takashi Sato
2005-12-08 14:27                   ` Trond Myklebust
2005-12-08 14:50                     ` Anton Altaparmakov [this message]
2005-12-08 15:03                       ` Trond Myklebust
2005-12-10 11:22                     ` Takashi Sato
     [not found] <5eVqw-2ug-61@gated-at.bofh.it>
2005-12-03  2:19 ` Bodo Eggert
  -- strict thread matches above, loose matches on Subject: below --
2005-12-01 12:00 Takashi Sato
2005-12-01 12:39 ` Jörn Engel
2005-12-01 12:52 ` Jörn Engel
2005-12-01 13:52   ` Avi Kivity
2005-12-01 14:32 ` Dave Kleikamp
2005-12-02 13:18   ` Takashi Sato
2005-12-02 14:11     ` Dave Kleikamp
2005-12-02 18:58     ` Andreas Dilger
2005-12-03 13:00       ` Takashi Sato
2005-12-05  8:11         ` Andreas Dilger
2005-12-05 12:35           ` Takashi Sato
2005-12-05 13:34           ` Trond Myklebust
2005-12-01 14:53 ` Al Viro

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=1134053446.17436.51.camel@imp.csi.cam.ac.uk \
    --to=aia21@cam.ac.uk \
    --cc=adilger@clusterfs.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaggy@austin.ibm.com \
    --cc=sho@bsd.tnes.nec.co.jp \
    --cc=trond.myklebust@fys.uio.no \
    /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;
as well as URLs for NNTP newsgroup(s).