XFS - blkgetsize64

parisc-linux Stefan Pfetzing 5 participants 10 messages Sep 4, 2002 – Sep 5, 2002

Share & tools

Stefan Pfetzing

author

2002-09-04 14:30 UTC #0 lore raw

Hi,

I just tried to get XFS working on my C200 (I've got a new IBM SCSI disk.) and mkfs.xfs always got the size of the Device (/dev/sda5) wrong. (it complained about not getting with lseek64 to that position...)
(I don't have the correct error message ready, but I can check, if its needed)

After I changed the libxfs to only use the BLKGETSIZE64 ioctl, it works fine now. (Eric Sandeen pointed me to this)

So he said, perhaps there is a bug in the SCSI (lasi?) driver.

bye

Stefan

P.S.: I'm using 2.4.19-pa9 with a self made diff from vanilla 2.4.19 against XFS CVS. (the patch did in nearly cleanly)

Signature · 2 lines

        http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.

Grant Grundler

2002-09-04 16:51 UTC #1 lore raw

Quoted 2 lines · Stefan Pfetzing

mkfs.xfs always got the size of the Device (/dev/sda5) wrong. (it complained about not getting with lseek64 to that position...)

...

Quoted 1 line

So he said, perhaps there is a bug in the SCSI (lasi?) driver.

I don't think it's the driver.

lseek64 must be getting redirected to lseek(). Linux kernel only supports "lseek".
See "struct file_operations" in include/linux/fs.h.

loff_t is a 64-bit type.
include/linux/types.h:typedef __kernel_loff_t loff_t;
include/asm/posix_types.h:typedef long long __kernel_loff_t;

Quoted 2 lines

P.S.: I'm using 2.4.19-pa9 with a self made diff from vanilla 2.4.19 against XFS CVS. (the patch did in nearly cleanly)

Are you running 32-bit or 64-bit kernel?
I want to know if arch/parisc/kernel/sys_parisc32.c might be the problem.

grant

Randolph Chung

2002-09-04 18:07 UTC #2 lore raw

Quoted 1 line

I don't think it's the driver.

no, not the driver...

Quoted 2 lines

lseek64 must be getting redirected to lseek().
Linux kernel only supports "lseek".

lseek64 is translated to a sys_llseek (you can see that with strace).

Quoted 4 lines

See "struct file_operations" in include/linux/fs.h. loff_t is a 64-bit type.
include/linux/types.h:typedef __kernel_loff_t loff_t;
include/asm/posix_types.h:typedef long long __kernel_loff_t;

we need to do some tricks to get this right ... some of the other syscalls are fixed, but this one is not it seems.

Quoted 1 line

I want to know if arch/parisc/kernel/sys_parisc32.c might be the problem.

fwiw sys_llseek is not translated.

randolph

John David Anglin

2002-09-04 18:43 UTC #3 lore raw

[parisc-linux] GCC and quad-precision floating point

I have just implemented some fixes and changed the long double size to 128 bits on the hppa64 GCC ports. For parisc-linux, the long double support should be 128 bits (both for 32 and 64 bit) but we are currently stuck at 64 bits because we are missing a bunch of quad library calls:

_U_Qfadd, _U_Qfsub, _U_Qfmpy, _U_Qfdiv, _U_Qfneg, _U_Qfsqrt, _U_Qfabs, _U_Qfmin, _U_Qfmax, _U_Qfcnvff_sgl_to_quad, _U_Qfcnvff_dbl_to_quad, _U_Qfcnvff_quad_to_sgl, _U_Qfcnvff_quad_to_dbl, _U_Qfcnvxf_sgl_to_quad, _U_Qfcnvxf_dbl_to_quad, _U_Qfcnvfxt_quad_to_sgl, _U_Qfcnvfxt_quad_to_usgl, _U_Qfcnvfxt_quad_to_udbl, _U_Qfcnvfxt_quad_to_dbl, _U_Qfeq, _U_Qfne, _U_Qfgt, _U_Qfge, _U_Qflt, _U_Qfle.

There are probably some more for unordered comparisons.

Any chance that someone with contacts inside HP, might be able to obtain the source code for these functions? They are really part of the ABI.

While it's relatively straightforward to implement these using the quad-precision instructions in the PA 2.0 architecture for the 64-bit port, it's non trivial to implement them for earlier architectures using the 32-bit port.

Dave

Signature · 2 lines

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Carlos O'Donell

2002-09-04 19:15 UTC #4 lore raw

Re: [parisc-linux] GCC and quad-precision floating point

Quoted 18 lines

I have just implemented some fixes and changed the long double size to 128 bits on the hppa64 GCC ports. For parisc-linux, the long double support should be 128 bits (both for 32 and 64 bit) but we are currently stuck at 64 bits because we are missing a bunch of quad library calls:
_U_Qfadd, _U_Qfsub, _U_Qfmpy, _U_Qfdiv, _U_Qfneg, _U_Qfsqrt, _U_Qfabs, _U_Qfmin, _U_Qfmax, _U_Qfcnvff_sgl_to_quad, _U_Qfcnvff_dbl_to_quad, _U_Qfcnvff_quad_to_sgl, _U_Qfcnvff_quad_to_dbl, _U_Qfcnvxf_sgl_to_quad, _U_Qfcnvxf_dbl_to_quad, _U_Qfcnvfxt_quad_to_sgl, _U_Qfcnvfxt_quad_to_usgl, _U_Qfcnvfxt_quad_to_udbl, _U_Qfcnvfxt_quad_to_dbl, _U_Qfeq, _U_Qfne, _U_Qfgt, _U_Qfge, _U_Qflt, _U_Qfle.
There are probably some more for unordered comparisons.
Any chance that someone with contacts inside HP, might be able to obtain the source code for these functions? They are really part of the ABI.

Quoted 6 lines

While it's relatively straightforward to implement these using the quad-precision instructions in the PA 2.0 architecture for the 64-bit port, it's non trivial to implement them for earlier architectures using the 32-bit port.
Dave

Randolph and I were discussing borrowing from gmp to implement some of these for the earlier 32-bit processors. Thought it seems that this may break the HPUX compatibility?

gmp seems to have support for:

add, sub, multiply, div, neg, sqrt, abs, min, max equals, not-equals, greater-than, greather-than-or-equal, less-than, less-than-or-equal.

The 'cnv' functions need to be addressed:

	single -> quad
	double -> quad
	quad   -> single
	quad   -> double
	quad   -> unsigned single
	quad   -> unsigned double

Under certain conditions of float-float, float-fixed, float-fixed&truncate. This will have to follow the HPUX convention?

John David Anglin

2002-09-04 19:59 UTC #5 lore raw

Re: [parisc-linux] GCC and quad-precision floating point

Quoted 3 lines

Randolph and I were discussing borrowing from gmp to implement some of these for the earlier 32-bit processors. Thought it seems that this may break the HPUX compatibility?

I would guess that that the best compatibility would be obtained with the HP functions. As far as I can tell, gmp does not use IEEE standard data types. Thus, concepts of nans, snans, unordered if present at all in gmp would differ.

GCC can only deal with floating data in IEEE format. So, conversion would have to be done for all operations.

I presume that the HPUX compatibility is just for static binaries (i.e., there is no shared library support). In this case, the routines would be compiled into hpux binaries. So, I don't think much additional would be needed at an os level.

Dave

Signature · 2 lines

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Stefan Pfetzing

author

2002-09-04 18:28 UTC #6 lore raw

In reply to Grant Grundler

Hi,

Quoted 1 line · Grant Grundler

Stefan Pfetzing wrote:

[snip]

Quoted 5 lines

Quoted 2 lines
P.S.: I'm using 2.4.19-pa9 with a self made diff from vanilla 2.4.19 against XFS CVS. (the patch did in nearly cleanly)
Are you running 32-bit or 64-bit kernel?
I want to know if arch/parisc/kernel/sys_parisc32.c might be the problem.

I'm running a 32bit kernel, since some time ago I had problems with 64bit and cdrecord.

bye

Stefan

Signature · 2 lines

        http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.

Stefan Pfetzing

author

2002-09-04 20:57 UTC #7 lore raw

Hum, replying to myself...

Quoted 10 lines · Stefan Pfetzing

Quoted 1 line · Grant Grundler
Stefan Pfetzing wrote:
[snip]
Quoted 5 lines
Quoted 2 lines
P.S.: I'm using 2.4.19-pa9 with a self made diff from vanilla 2.4.19 against XFS CVS. (the patch did in nearly cleanly)
Are you running 32-bit or 64-bit kernel?
I want to know if arch/parisc/kernel/sys_parisc32.c might be the problem.
I'm running a 32bit kernel, since some time ago I had problems with 64bit and cdrecord.

I just got a blkgetsize* testprogram...
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62038)

---snip---

root@hp:~# ./blkgetsizetester /dev/sda2
Device size is 83968 blocks (42991616 bytes)
Device size per BLKGETSIZE64 is 12345 bytes
root@hp:~# ./blkgetsizetester /dev/sda5 
Device size is 1026016 blocks (525320192 bytes)
Device size per BLKGETSIZE64 is 12345 bytes
root@hp:~#
---snip---

I think thats the problem with xfs... well at least blkgetsize64 should report an error, if its not working correctly.

bye

Stefan

Signature · 2 lines

        http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.

Randolph Chung

2002-09-05 04:34 UTC #8 lore raw

Quoted 2 lines

I just got a blkgetsize* testprogram...
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62038)

the test program has a nasty bug in it...
#define BLKGETSIZE64 _IOR(0x12,114,sizeof(unsigned long long)) /* return device

that's wrong.. it should be
#define BLKGETSIZE64 _IOR(0x12,114,unsigned long long) /* return device

randolph

Signature · 3 lines

Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Randolph Chung

2002-09-05 05:24 UTC #9 lore raw

In reply to Stefan Pfetzing

Quoted 3 lines

I just tried to get XFS working on my C200 (I've got a new IBM SCSI disk.) and mkfs.xfs always got the size of the Device (/dev/sda5) wrong. (it complained about not getting with lseek64 to that position...)

64-bit kernel:

tausq@gsyprf11:~$ ls -l tst
-r-x--xr--    1 tausq    tausq    1099511627777 Sep  4 22:18 tst*
tausq@gsyprf11:~$ ./tt tst
lseek64(3,0,SEEK_END) = 1048576M

on my gecko (32-bit)

randolph@frodo:~$ sudo ./t /dev/sda3
lseek64(3,0,SEEK_END) = 1949M

seems to work ok?

randolph

Signature · 3 lines

Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/