Details
-
Bug
-
Resolution: Fixed
-
Minor
-
Lustre 2.4.0
-
3
-
7750
Description
mdt_cross_open() uses a slightly different test than is used elsewhere to detect nefarious attempts at creating striping by opening files for write using their FIDs.
For files on MDT0 this is handled "correctly":
# MDSCOUNT=2 llmount.sh # cd /mnt/lustre # multiop f0 m # lfs path2fid f0 [0x280000400:0x1:0x0] # multiop .lustre/fid/[0x280000400:0x1:0x0] oO_WRONLY:O_LOV_DELAY_CREATE # lfs setstripe -c2 .lustre/fid/[0x280000400:0x1:0x0] # lfs getstripe .lustre/fid/[0x280000400:0x1:0x0]
Now for a file on MDT1:
# lfs mkdir -i1 d1 # multiop d1/f1 m # lfs path2fid d1/f1 [0x2c0000400:0x2:0x0] # multiop .lustre/fid/[0x2c0000400:0x2:0x0] oO_WRONLY:O_LOV_DELAY_CREATE open: Operation not permitted # lfs setstripe -c2 .lustre/fid/[0x2c0000400:0x2:0x0] unable to open '.lustre/fid/[0x2c0000400:0x2:0x0]': Operation not permitted (1) error: setstripe: create stripe file '.lustre/fid/[0x2c0000400:0x2:0x0]' failed # lfs getstripe .lustre/fid/[0x2c0000400:0x2:0x0] .lustre/fid/[0x2c0000400:0x2:0x0] has no stripe info
I think that all these checks for fid_is_obf() are somewhat silly and that users of .lustre/fid should just be expected to use O_LOV_DELAY_CREATE.
Attachments
Issue Links
- is related to
-
LU-3272 block rename for FID_SEQ_DOT_LUSTRE, unify weird FID handling
- Open