CephFS: Failure in running smb2.durable-open

[anoopcs9]

Following error is seen with CephFS backed shares on running smb2.durable-open.alloc-size.

smbtorture 4.21.0pre1-GIT-b71f729698f
Using seed 1715837428
time: 2024-05-16 05:30:28.610195
test: alloc-size
time: 2024-05-16 05:30:28.611811
time: 2024-05-16 05:30:29.358999
failure: alloc-size [
(../../source4/torture/smb2/durable_open.c:2589): wrong value for (&io)->out.alloc_size got 0x1200 - should be 0x2000
]

[anoopcs9]

Here's how the test progresses:

• Creates a regular empty file with initial allocation size of 4096B.
• Writes 1 Byte and verifies the updated allocation size i.e, stx_blocks * 512(8*512).
• Writes another 4096 bytes so that it goes beyond initial allocation size and verifies the updated allocation size.
  • In case of local file systems with block size of 4096B(4KB) allocation size is doubled(16*512) as expected.
  • Whereas in CephFS stx_blocks is populated by the quotient of file size divided in units of 512(9*512) which breaks the expectation from test.

[synarete]

@anoopcs9 I am using the following shell commands to reproduce:

truncate -s 4096 test1
dd if=/dev/urandom of=test1 bs=1 count=1 conv=notrunc status=none
dd if=/dev/urandom of=test1 bs=1 count=4096 seek=1 conv=notrunc status=none
stat test1 --format="%n %s %b %B"

and indeed, on cephfs (direct mount and via samba) I get:

test1 4097 9 512

while on xfs I get:

test1 4097 16 512

However, note that linux man 2 stat says that:

Use of the st_blocks and st_blksize fields may be less portable.

I suspect this is one of those cases.

[anoopcs9]

_vfsceph backed shares errors out(NT_STATUS_OBJECT_NAME_NOT_FOUND) way earlier in these durable handle tests during reconnect as it fails to precisely match btime.

[anoopcs9]

_vfsceph backed shares errors out(NT_STATUS_OBJECT_NAME_NOT_FOUND) way earlier in these durable handle tests during reconnect as it fails to precisely match btime.

!3635 is a possible fix.

[anoopcs9]

_vfsceph backed shares errors out(NT_STATUS_OBJECT_NAME_NOT_FOUND) way earlier in these durable handle tests during reconnect as it fails to precisely match btime.

!3635 is a possible fix.

Above fix merged upstream.