All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Schmid <webmaster@rapidforum.com>
To: linux-kernel@vger.kernel.org
Subject: Problems with large block devices in 64 bit kernels
Date: Thu, 07 Sep 2006 15:19:24 +0200	[thread overview]
Message-ID: <45001C5C.3020700@rapidforum.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2417 bytes --]

Andries Brouwer wrote:

 > On Wed, Sep 06, 2006 at 10:54:42PM +0200, Christian Schmid wrote:
 >
 >> I run kernel 2.6.17.11 vanilla in 64 bit mode with 32 bit emulation.
 >> model name      : Intel(R) Xeon(R) CPU            5150  @ 2.66GHz
 >>
 >> Unfortunately there is no support for file-systems bigger than 2 TB in 64-bit mode with 32-bit 
emulation.
 >>
 >> erikm in #kernelnewbies told me to report it here:
 >>
 >> <Dragony> statfs("/MD2", 0xff8deca4)              = -1 EOVERFLOW (Value too large for defined 
data type)
 >
 >
 >
 > Hmm. statfs uses struct statfs which has a 4-byte f_blocks field,
 > and hence cannot hold larger values. You get what you ask for.
 >
 > statfs64 uses struct statfs64 which uses an 8-byte f_blocks field.
 >
 > (And then there is statvfs.)
 >
 > Andries


Hmm I dont think its that easy. Actually the max. value is 16 TB because of 232*4096 (block-size) 
and this works on a 32 bit kernel.

df on 32 bit kernel:
(See attached image. Sorry, this kernel has not the required network-driver included. Had to take a 
screenshot)

SAME df on 64 bit kernel:
write(1, "Filesystem           1K-blocks  "..., 67Filesystem           1K-blocks      Used Available 
Use% Mounted on
) = 67
statfs("/", {f_type=0x58465342, f_bsize=4096, f_blocks=732384, f_bfree=508015, f_files=2939776, 
f_ffree=2901955, f_namelen=255}) = 0
write(1, "/dev/md0               2929536  "..., 58/dev/md0               2929536    897476   2032060 
  31% /
) = 58
statfs("/proc", {f_type="PROC_SUPER_MAGIC", f_bsize=4096, f_blocks=0, f_bfree=0, f_files=0, 
f_ffree=0, f_namelen=255}) = 0
statfs("/MD1", {f_type=0x58465342, f_bsize=4096, f_blocks=4407104, f_bfree=4403156, 
f_files=17638656, f_ffree=17638645, f_namelen=255}) = 0
write(1, "/dev/md1              17628416  "..., 61/dev/md1              17628416     15792  17612624 
   1% /MD1
) = 61
statfs("/MD2", 0xffa30614)              = -1 EOVERFLOW (Value too large for defined data type)
write(2, "df: ", 4df: )                     = 4
write(2, "`/MD2\'", 6`/MD2')                  = 6
write(2, ": Value too large for defined da"..., 39: Value too large for defined data type) = 39
write(2, "\n", 1
)                       = 1
statfs("/dev/pts", {f_type=0x1cd1, f_bsize=4096, f_blocks=0, f_bfree=0, f_files=0, f_ffree=0, 
f_namelen=255}) = 0
munmap(0xf7eea000, 4096)                = 0

So its definetly something with the kernel.

Regards,
Christian Schmid

[-- Attachment #2: screen.png --]
[-- Type: image/png, Size: 34863 bytes --]

                 reply	other threads:[~2006-09-07 13:19 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=45001C5C.3020700@rapidforum.com \
    --to=webmaster@rapidforum.com \
    --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 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.