Details
-
Bug
-
Resolution: Fixed
-
Critical
-
Lustre 2.12.0, Lustre 2.10.3
-
None
-
sles12 lustre 2.10.3
-
2
-
9223372036854775807
Description
On lustre2.10.3 ifort lseek will return the wrong position when using append ">>" operation.
This can be reproduced on
client: sles12 lustre2.103 <–> server: lustre2.7.3
client: sles12 lustre2.103 <–> server: lustre2.10.3
hello.f
write(6,*) "hello world"
end
Working on sles11 and lustre2.7.3
> date > tt > date >> tt > cat tt Wed May 30 13:32:58 PDT 2018 Wed May 30 13:33:04 PDT 2018 > strace ./a.out >> tt ..... ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffffffbf80) = -1 ENOTTY (Inappropriate ioctl for device) fstat(1, {st_mode=S_IFREG|0600, st_size=58, ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffffffbf80) = -1 ENOTTY (Inappropriate ioctl for device) write(1, " hello world\n", 13) = 13 lseek(1, 0, SEEK_CUR) = 71 ftruncate(1, 71) = 0 > cat tt Wed May 30 13:32:58 PDT 2018 Wed May 30 13:33:04 PDT 2018 hello world
-
- Note lseek(1,0,SEEK_CUR) set at 71.
Not working on lustre2.10.3.
> rm tt
> date > tt
> date >> tt
> cat tt
Wed May 30 13:41:39 PDT 2018
Wed May 30 13:41:44 PDT 2018
> strace ./a.out >> tt
....
fstat(1, {st_mode=S_IFREG|0600, st_size=58, ...}) = 0
ioctl(1, TCGETS, 0x7fffffffbf80) = -1 ENOTTY (Inappropriate ioctl for device)
write(1, " hello world\n", 13) = 13
lseek(1, 0, SEEK_CUR) = 13
ftruncate(1, 13) = 0
pfe27:/nobackup/jchang> cat tt
Wed May 30 13pfe27:/nobackup/jchang>
*Note that it's lseek that is getting the **wrong* information about current position after the append.
Attachments
Issue Links
Activity
Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/32641/
Subject: LU-11069 llite: correct file position after appending writes
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: f8df907e8aaeaee559f913a68a345011a7aa1f23
Mahmoud
If all goes well it should land to master mid-next week.
Peter
The patch fixed the lseek issue in our fortran test. When can we expect for it to land.
$ date > tt $ date >> tt $ strace ./a.out >> tt .... ioctl(1, TCGETS, 0x7fffffff77a0) = -1 ENOTTY (Inappropriate ioctl for device) ioctl(1, TCGETS, 0x7fffffffbd00) = -1 ENOTTY (Inappropriate ioctl for device) fstat(1, {st_mode=S_IFREG|0600, st_size=58, ...}) = 0 ioctl(1, TCGETS, 0x7fffffffbd00) = -1 ENOTTY (Inappropriate ioctl for device) write(1, " hello world\n", 13) = 13 lseek(1, 0, SEEK_CUR) = 71 ftruncate(1, 71) = 0 ..... $ cat tt Fri Jun 8 16:00:58 PDT 2018 Fri Jun 8 16:01:01 PDT 2018 hello world
Hi Jay,
A port of the change to b2_10 is available at https://review.whamcloud.com/#/c/32661/2.
multiop.c: In function 'main':
multiop.c:677:4: error: implicit declaration of function 'llapi_get_ost_layout_v
ersion' [-Werror=implicit-function-declaration]
rc = llapi_get_ost_layout_version(fd, &layout_version);
^
cc1: all warnings being treated as errors
Makefile:1205: recipe for target 'multiop.o' failed
make[5]: *** [multiop.o] Error 1
John L. Hammond (john.hammond@intel.com) uploaded a new patch: https://review.whamcloud.com/32661
Subject: LU-11069 llite: correct file position after appending writes
Project: fs/lustre-release
Branch: b2_10
Current Patch Set: 1
Commit: 1f2e3e935946f02950b67e9359a5d4d28216fbfd
More problems in the patch when cherry-picked to b2_10 without being flagged as conflicts. It then caused compilation errors.
Could you please back port to b2_10? Thanks!
Hi Jay,
I encourage you to test the patch but please be aware that it has not completed full testing and review. In fact Jinshan pointed out an issue with the first patch set and I have submitted a second patch set. So we would not advise you to put this change into production just yet.
John L. Hammond (jhammond@whamcloud.com) merged in patch https://review.whamcloud.com/32661/
Subject:
LU-11069llite: correct file position after appending writesProject: fs/lustre-release
Branch: b2_10
Current Patch Set:
Commit: 7bc18a0083b27292dd912dba0ae1aa5010568fb4