remote fileio: st_ino truncated to 32 bits in vFile:stat/lstat

[Abhay Kandpal <abhay@linux.ibm.com>]

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

Hi Andrew,

I hit a failure in gdb.server/fileio-packets.exp on a machine whose filesystem uses inode numbers above 2^32.

All four stat/lstat checks fail, with every field matching except st_ino:

remote = {..., 'st_ino': 2161233200, ...}
local  = {..., 'st_ino': 122420317488, ...}

122420317488 = 0x1C80CE9BB0
2161233200  =   0x80CE9BB0

The field is 4 bytes wide in the protocol struct, while st_ino is 64-bit on Linux:

gdbsupport/fileio.h:130   fio_uint_t  fst_ino;
gdbsupport/fileio.cc:281  host_to_fileio_uint ((long) st->st_ino, fst->fst_ino);

fst_size, fst_blksize and fst_blocks in the same struct already use the 8-byte fio_ulong_t.
It reproduces on xfs (86 TB, largest inode 171801755018) and passes on ext4 (2 TB, largest inode 132907009),
so it depends on the filesystem rather than the architecture.

https://sourceware.org/bugzilla/show_bug.cgi?id=34567 <https://sourceware.org/bugzilla/show_bug.cgi?id=34567>

Before writing anything I wanted to ask how you'd prefer this handled.

struct fio_stat is shared between the vFile packets and the older F-packet protocol,
so widening fst_ino changes the wire layout for both.

I can see three options:

  1. Widen the shared field.
  2. Add a separate wider struct used only by the vFile packets,
     along the lines of your reasoning in c29a37f7417 about those packetsstill being new.
  3. Negotiate the wider format through qSupported.

The second seems the least disruptive, but I don't have a good sense of who else implements these packets.

Also worth deciding at the same time, if the layout is being revised:
fst_dev and fst_rdev are fio_uint_t although dev_t is 64-bit, and the three timestamps are 4 bytes.

Thanks,
Abhay


[-- Attachment #2: Type: text/html, Size: 3037 bytes --]