On 8/27/18 11:43 AM, Andi Kleen wrote:
>
> Adding linux-fsdevel. Keeping full quote for context.
>
> On Mon, Aug 27, 2018 at 10:12:54AM +0200, Carlos Maiolino wrote:
>> Hi.
>>
>> On Sat, Aug 25, 2018 at 09:25:33PM -0500, Eric Sandeen wrote:
>>>
>>>
>>> On 8/25/18 9:09 AM, Andi Kleen wrote:
>>>> On Fri, Aug 24, 2018 at 07:58:05PM -0500, Eric Sandeen wrote:
>>>>> On 8/24/18 6:37 PM, Andi Kleen wrote:
>>>>>>
>>>>>> Seen this a few times now with recent kernels:
>>>>>
>>>>> Hi Andi -
>>>>>
>>>>> Dumb question maybe, but just to be clear -
>>>>> Was this an RO mount on an RO device, or something else?
>>>>> What type of mount was this?
>>>>
>>>> Was just a normal RW partition on a normal SSD. I didn't do anything
>>>> special to make it RO.
>>>
>>> I don't know why it shows up as RO at this point, but maybe this fixes it:
>>>
>>> commit b089cfd95d32638335c551651a8e00fd2c4edb0b
>>> Author: Jens Axboe <axboe@xxxxxxxxx>
>>> Date: Tue Aug 14 10:52:40 2018 -0600
>>>
>>> block: don't warn for flush on read-only device
>>>
>>> Don't warn for a flush issued to a read-only device. It's not strictly
>>> a writable command, as it doesn't change any on-media data by itself.
>>>
>>> Reported-by: Stefan Agner <stefan@xxxxxxxx>
>>> Fixes: 721c7fc701c7 ("block: fail op_is_write() requests to read-only partitions")
>>> Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
>>
>> This kind of 'problem' is being reported quite often now. It all started with
>> commit:
>>
>> commit 721c7fc701c71f693307d274d2b346a1ecd4a534
>> Author: Ilya Dryomov <idryomov@xxxxxxxxx>
>> Date: Thu Jan 11 14:09:11 2018 +0100
>>
>> block: fail op_is_write() requests to read-only partitions
>>
>> Which basically added a generic check for RO devices into generic_make_request()
>> code path, as a way to enforce ioctl(BLKROSET), so far, write requests were
>> never checked.
>>
>>
>> Then, Linus applied the following commit:
>>
>> commit a32e236eb93e62a0f692e79b7c3c9636689559b9
>> Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
>> Date: Fri Aug 3 12:22:09 2018 -0700
>>
>> Partially revert "block: fail op_is_write() requests to read-only partitions"
>>
>> Once a few layers like LVM, didn't expect the device to enforce RO, which kept
>> writing to the device while snapshotting, even if the device has been marked as
>> RO.
>>
>> And then came the commit mentioned by Eric:
>>
>> commit b089cfd95d32638335c551651a8e00fd2c4edb0b
>> Author: Jens Axboe <axboe@xxxxxxxxx>
>> Date: Tue Aug 14 10:52:40 2018 -0600
>>
>> block: don't warn for flush on read-only device
>>
>>
>> Which relaxed the rules a bit and basically let flushes to proceed without warnings.
>>
>> Essentially, this isn't a XFS problem, and most likely you are using XFS on top
>> of some layer like LVM, and/or using snapshots, and your underlying volume went
>> read-only behind XFS for some reason.
>
> Ok, so the blame is assigned, but the question is still how to avoid the
> warning:
>
> (1) either XFS needs to check for read only underlying more often
> or
> (2) the warning needs to be removed.
>
> I assume (2) is far easier. Is (1) even possible without races?
> What is preferred?
Seems like the first question to answer is: why is your "plain RW partition
on an SSD" suddenly reporting itself as RO during umount?
That said, I don't see a reason for xfs to continue to check for an RO partition
during operation, if for some unexpected reason a block device starts returning
EIO due to a device going readonly, normal error handling should kick in.
-Eric
