mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Dave Kleikamp <shaggy@austin.ibm.com>
Cc: Takashi Sato <sho@tnes.nec.co.jp>,
	"'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: Wed, 07 Dec 2005 10:34:30 -0500	[thread overview]
Message-ID: <1133969671.27373.47.camel@lade.trondhjem.org> (raw)
In-Reply-To: <1133967716.8910.5.camel@kleikamp.austin.ibm.com>

On Wed, 2005-12-07 at 09:01 -0600, Dave Kleikamp wrote:
> On Wed, 2005-12-07 at 08:52 -0500, Trond Myklebust wrote:
> > On Wed, 2005-12-07 at 19:57 +0900, Takashi Sato wrote:
> > 
> > > On my previous mail, I said that CONFIG_LBD should not determine
> > > whether large single files is enabled.  But after further
> > > consideration, on such a small system that CONFIG_LBD is disabled,
> > > using large filesystem over network seems to be very rare.
> > > So I think that the type of i_blocks should be sector_t.
> > 
> > ???? Where do you get this misinformation from?
> 
> Without some kind of counter-example, I would tend to agree with
> Takashi.  In what scenerio would someone build a kernel with CONFIG_LBD
> disabled, yet would be needing to access files > 2TB across the network?

The word "filesystem" confused me. In my experience > 2TB filesystems
tend to be the norm for NFS shared systems these days, and so the fact
that 'struct kstatfs' uses sector_t irks me.
Access to > TB files is not unheard of in HPC circles (particularly in
the case of simulations), but these files tend to be pretty sparse, so
the block counts are not necessarily that large.

My point stands, though. whether or not sector_t may indeed be the right
size as far as i_block is concerned, a quick grep through (fs|block)/*.c
shows you that as a type, it is anything but a count of the number of
blocks in a file.

If you really want a variable size type here, then the right thing to do
is to define a __kernel_blkcnt_t or some such thing, and hide the
configuration knob for it somewhere in the arch-specific Kconfigs.

Cheers,
  Trond


  reply	other threads:[~2005-12-07 15:35 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-06 12:42 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 [this message]
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
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=1133969671.27373.47.camel@lade.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=adilger@clusterfs.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaggy@austin.ibm.com \
    --cc=sho@tnes.nec.co.jp \
    /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®