lkml.org 
[lkml]   [2020]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: BUG:loop:blk_update_request: I/O error, dev loop6, sector 49674 op 0x9:(WRITE_ZEROES)
    From
    Date


    On 5/14/20 12:41 AM, Darrick J. Wong wrote:
    > [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.

    Many thanks for your detailed reply:) No good method for detecting
    fallocte support is a real problem. And the way to "fix" you mentioned
    do is a good workaround for the current satuation.


    Best regards,
    Yanfei

    >
    > --D
    >
    >>>
    >>>
    >>> Thanks,
    >>>
    >>> Yanfei
    >>>
    >>>
    >>>
    >>>
    >>>
    >>
    >>
    >> --
    >> Jens Axboe
    >>

    \
     
     \ /
      Last update: 2020-05-14 18:10    [W:2.783 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site