linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Cc: "Jørgen Hansen" <Jorgen.Hansen@wdc.com>
Subject: Re: [PATCH 1/7] zonefs: Detect append writes at invalid locations
Date: Thu, 12 Jan 2023 17:26:00 +0900	[thread overview]
Message-ID: <8cf5ed66-2b96-d9da-a619-1cf29ffeba6a@opensource.wdc.com> (raw)
In-Reply-To: <78d06124-8dc6-d77a-b519-ee5d4847b479@wdc.com>

On 1/12/23 16:33, Johannes Thumshirn wrote:
> On 12.01.23 06:18, Damien Le Moal wrote:
>> On 1/12/23 07:08, Damien Le Moal wrote:
>>> On 1/11/23 21:23, Johannes Thumshirn wrote:
>>>> On 10.01.23 14:08, Damien Le Moal wrote:
>>>>> Using REQ_OP_ZONE_APPEND operations for synchronous writes to sequential
>>>>> files succeeds regardless of the zone write pointer position, as long as
>>>>> the target zone is not full. This means that if an external (buggy)
>>>>> application writes to the zone of a sequential file underneath the file
>>>>> system, subsequent file write() operation will succeed but the file size
>>>>> will not be correct and the file will contain invalid data written by
>>>>> another application.
>>>>>
>>>>> Modify zonefs_file_dio_append() to check the written sector of an append
>>>>> write (returned in bio->bi_iter.bi_sector) and return -EIO if there is a
>>>>> mismatch with the file zone wp offset field. This change triggers a call
>>>>> to zonefs_io_error() and a zone check. Modify zonefs_io_error_cb() to
>>>>> not expose the unexpected data after the current inode size when the
>>>>> errors=remount-ro mode is used. Other error modes are correctly handled
>>>>> already.
>>>>
>>>> This only happens on ZNS and null_blk, doesn't it? On SCSI the Zone Append
>>>> emulation should catch this error before.
>>>
>>> Yes. The zone append will fail with scsi sd emulation so this change is
>>> not useful in that case. But null_blk and ZNS drives will not fail the
>>> zone append, resulting in a bad file size without this check.
>>
>> Let me retract that... For scsi sd, the zone append emulation will do its
>> job if an application writes to a zone under the file system. Then zonefs
>> issuing a zone append will also succeed and we end up with the bad inode size.
>>
>> We would get a zone append failure in zonefs with scsi sd if the
>> corruption to the zone was done with a passthrough command as these will
>> not result in sd_zbc zone write pointer tracking doing its job.
>>
> 
> But then the error recovery procedures in sd_zbc should come into place.

Yes, for the passthrough case, because it ends up generating a failed
write, which zonefs catches and handles. All good in that case. It remains
that the patch is also necessary for scsi if the corruption happens with
something like dd, which will be seem by sd_zbc. So subsequent zone append
from zonefs will succeed, even though zonefs is not aware that the wp
changed...

> 
> Anyways for ZNS and null_blk this is an improvement:
> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>

-- 
Damien Le Moal
Western Digital Research


  reply	other threads:[~2023-01-12  8:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-10 13:08 [PATCH 0/7] Reduce zonefs memory usage Damien Le Moal
2023-01-10 13:08 ` [PATCH 1/7] zonefs: Detect append writes at invalid locations Damien Le Moal
2023-01-11 12:23   ` Johannes Thumshirn
2023-01-11 22:08     ` Damien Le Moal
2023-01-12  5:18       ` Damien Le Moal
2023-01-12  7:33         ` Johannes Thumshirn
2023-01-12  8:26           ` Damien Le Moal [this message]
2023-01-10 13:08 ` [PATCH 2/7] zonefs: Reorganize code Damien Le Moal
2023-01-11 16:12   ` Johannes Thumshirn
2023-01-10 13:08 ` [PATCH 3/7] zonefs: Simplify IO error handling Damien Le Moal
2023-01-13 10:09   ` Johannes Thumshirn
2023-01-10 13:08 ` [PATCH 4/7] zonefs: Reduce struct zonefs_inode_info size Damien Le Moal
2023-01-13 10:11   ` Johannes Thumshirn
2023-01-10 13:08 ` [PATCH 5/7] zonefs: Separate zone information from inode information Damien Le Moal
2023-01-13 11:30   ` Johannes Thumshirn
2023-01-10 13:08 ` [PATCH 6/7] zonefs: Dynamically create file inodes when needed Damien Le Moal
2023-01-16 11:46   ` Johannes Thumshirn
2023-01-16 12:17     ` Damien Le Moal
2023-01-10 13:08 ` [PATCH 7/7] zonefs: Cache zone group directory inodes Damien Le Moal
2023-01-16 11:49   ` Johannes Thumshirn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8cf5ed66-2b96-d9da-a619-1cf29ffeba6a@opensource.wdc.com \
    --to=damien.lemoal@opensource.wdc.com \
    --cc=Johannes.Thumshirn@wdc.com \
    --cc=Jorgen.Hansen@wdc.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).