[add fsdevel to cc] On Tue, May 12, 2020 at 08:22:08PM -0600, Jens Axboe wrote: > On 5/12/20 8:14 PM, Xu, Yanfei wrote: > > Hi, > > > > After operating the /dev/loop which losetup with an image placed in**tmpfs, > > > > I got the following ERROR messages: > > > > ----------------[cut here]--------------------- > > > > [ 183.110770] blk_update_request: I/O error, dev loop6, sector 524160 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0 > > [ 183.123949] blk_update_request: I/O error, dev loop6, sector 522 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0 > > [ 183.137123] blk_update_request: I/O error, dev loop6, sector 16906 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0 > > [ 183.150314] blk_update_request: I/O error, dev loop6, sector 32774 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0 > > [ 183.163551] blk_update_request: I/O error, dev loop6, sector 49674 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0 > > [ 183.176824] blk_update_request: I/O error, dev loop6, sector 65542 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0 > > [ 183.190029] blk_update_request: I/O error, dev loop6, sector 82442 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0 > > [ 183.203281] blk_update_request: I/O error, dev loop6, sector 98310 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0 > > [ 183.216531] blk_update_request: I/O error, dev loop6, sector 115210 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0 > > [ 183.229914] blk_update_request: I/O error, dev loop6, sector 131078 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0 > > > > > > I have found the commit which introduce this issue by git bisect : > > > > commit :efcfec57[loop: fix no-unmap write-zeroes request behavior] > > Please CC the author of that commit too. Leaving the rest quoted below. > > > Kernrel version: Linux version 5.6.0 > > > > Frequency: everytime > > > > steps to reproduce: > > > > 1.git clone mainline kernel > > > > 2.compile kernel with ARCH=x86_64, and then boot the system with it > > > > (seems other arch also can reproduce it ) > > > > 3.make an image by "dd of=/tmp/image if=/dev/zero bs=1M count=256" > > > > *4.**place the image in tmpfs directory* > > > > 5.losetup /dev/loop6 /PATH/TO/image > > > > 6.mkfs.ext2 /dev/loop6 > > > > > > Any comments will be appreciated. Hm, you got IO failures here because shmem_fallocate doesn't support FL_ZERO_RANGE range. That might not be too hard to add, but there's a broader problem of detecting fallocate support-- The loop driver assumes that if the file has an fallocate method then it's safe to set max_discard_sectors (and now max_write_zeroes_sectors) to UINT_MAX>>9. There's currently no good way to detect which modes are supported by a filesystem's ->fallocate function, or to discover the required granularity. Right now we tell application developers that the way to discover the conditions under which fallocate will work is to try it and see if they get EOPNOTSUPP. One way to "fix" this would be to fix lo_fallocate to set RQF_QUIET if the filesystem returns EOPNOTSUPP, which gets rid of the log messages. We probably ought to zero out the appropriate max_*_sectors if we get EOPNOTSUPP. --D > > > > > > Thanks, > > > > Yanfei > > > > > > > > > > > > > -- > Jens Axboe >
