From: Andreas Dilger <adilger@clusterfs.com>
To: Steven French <sfrench@us.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: statfs64 missing
Date: Thu, 17 Oct 2002 15:55:05 -0600 [thread overview]
Message-ID: <20021017215505.GB14989@clusterfs.com> (raw)
In-Reply-To: <OF6D978045.B4B59726-ON87256C55.006F1ED5@boulder.ibm.com>
On Oct 17, 2002 15:28 -0500, Steven French wrote:
> With big SAN based arrays of disks running under some of the high end
> CIFS based server appliances from EMC, NetApp etc. it would not be
> surprising to me to see an overflow problem for the 32 bit statfs fields
> today (mapping from the values in the FILE_SYSTEM_INFO returned by the
> server to statfs struct on i386 clients) unless the local fs lies
> about the block size. For the cifs vfs adding a statfs64 func would
> certainly be technically feasible from the protocol's perspective and
> pretty easy.
Yes, I hit this problem a month or two ago with Lustre - the 90TB
filesystem we are testing on wrapped and I thought it was a problem
in our code until I did some more digging. However, lying about
the blocksize isn't a big loss, since we prefer 64kB vector page I/O
over the network anyways for performance reasons, even though the
backing stores actually use 4kB blocksize.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
next prev parent reply other threads:[~2002-10-17 21:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-17 20:28 Steven French
2002-10-17 21:55 ` Andreas Dilger [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-10-17 21:27 Petr Vandrovec
2002-10-16 14:06 Andi Kleen
2002-10-16 14:16 ` Trond Myklebust
[not found] ` <15789.64263.606518.921166@wombat.chubb.wattle.id.au>
2002-10-17 0:01 ` Andi Kleen
2002-10-17 19:41 ` Benjamin LaHaise
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=20021017215505.GB14989@clusterfs.com \
--to=adilger@clusterfs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sfrench@us.ibm.com \
/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®