Wang Shilong (wshilong@ddn.com) uploaded a new patch: http://review.whamcloud.com/20478
Subject: LU-8210 osd-ldiskfs: fix setting pages PageUptodate state
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: f8630c9a585c97550405fa5cbb9f0d48ff4a37c8
Intresting thing is that we should always reproduce this problem in rhel7 platform, but I don't see
it reproduced in Intel autotest platform, but we could reproduce it in our environment.
53 * drivers should _never_ use the all version - the bio may have been split
154 * before it got to the driver and the driver won't own all of it
155 */
156 #define bio_for_each_segment_all(bvl, bio, i) \
157 for (i = 0; \
158 bvl = bio_iovec_idx((bio), (i)), i < (bio)->bi_vcnt; \
159 i++)
160
161 #define bio_for_each_segment(bvl, bio, i) \
162 for (i = (bio)->bi_idx; \
163 bvl = bio_iovec_idx((bio), (i)), i < (bio)->bi_vcnt; \
164 i++)
Here is difference between two interface, bio_for_each_segment_all() start from index,0
while bio_for_each_segment start from @bi_idx, while @bi_idx might change in bio_advance()
during IO handling.
Aslo Looking from How Current upstream Filesystem handle page state updates
in end IO:
[root@server11 fs]# git grep bio_for_each_segment_all
btrfs/compression.c: bio_for_each_segment_all(bvec, cb->orig_bio, i)
btrfs/disk-io.c: bio_for_each_segment_all(bvec, bio, i) {
btrfs/extent_io.c: bio_for_each_segment_all(bvec, bio, i) {
btrfs/extent_io.c: bio_for_each_segment_all(bvec, bio, i) {
btrfs/extent_io.c: bio_for_each_segment_all(bvec, bio, i) {
btrfs/inode.c: bio_for_each_segment_all(bvec, bio, i)
btrfs/inode.c: bio_for_each_segment_all(bvec, &io_bio->bio, i) {
btrfs/inode.c: bio_for_each_segment_all(bvec, bio, i) {
btrfs/inode.c: bio_for_each_segment_all(bvec, &io_bio->bio, i) {
crypto/crypto.c: bio_for_each_segment_all(bv, bio, i) {
direct-io.c: bio_for_each_segment_all(bvec, bio, i) {
exofs/ore.c: bio_for_each_segment_all(bv, bio, i) {
exofs/ore_raid.c: bio_for_each_segment_all(bv, bio, i) {
ext4/page-io.c: bio_for_each_segment_all(bvec, bio, i) {
ext4/readpage.c: bio_for_each_segment_all(bv, bio, i) {
ext4/readpage.c: bio_for_each_segment_all(bv, bio, i) {
f2fs/data.c: bio_for_each_segment_all(bvec, bio, i) {
f2fs/data.c: bio_for_each_segment_all(bvec, bio, i) {
f2fs/data.c: bio_for_each_segment_all(bvec, io->bio, i) {
gfs2/lops.c: bio_for_each_segment_all(bvec, bio, i) {
gfs2/meta_io.c: bio_for_each_segment_all(bvec, bio, i) {
logfs/dev_bdev.c: bio_for_each_segment_all(bvec, bio, i) {
mpage.c: bio_for_each_segment_all(bv, bio, i) {
I am still wondering why Intel autotest could pass this test, maybe I miss something here...........
I see from Documentation/block/biodoc.txt
- Drivers which can't process a large bio in one shot can use the bi_idx
484 field to keep track of the next bio_vec entry to process.
485 (e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE)
486 [TBD: Should preferably also have a bi_voffset and bi_vlen to avoid modifying
487 bi_offset an len fields]
So this problem might be related to Specific Driver which can explain
why we could reproduce it in our environment, however, we still need fix this issue
In Lustre.
Yang Sheng
Could you please advise on this issue?
Thanks
Peter
Hi, Wang,
Do you mind provide which type disk driver apply in your test environment. I am interesting to do a reproduction.
Thanks,
YangSheng
Hi Sheng,
Qemu configurations something like this:
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='none'/>
<source file='/home/vms/autotest-el7.2-vm5b.img'/>
<target dev='sdb' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>
Regards,
Shilong
Many thanks for your help.
Thanks,
YangSheng
Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/20478/
Subject: LU-8210 osd-ldiskfs: fix setting pages PageUptodate state
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 5e5e4ae2be4bc377f0f896163ae59bf338c4250c
Landed for 2.9
This patch breaks support with the latest kernels 
Is the lloop driver that breaks.
Luckily I thought we are deleting lloop, so that would be the easiest fix?
The default loop doesn't support direct I/O until the 4.6 kernel if I remember right. So we still need the fix for kernels between 3.16 <-> 4.5