Received-SPF: pass (google.com: domain of linux-kernel+bounces-93605-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <47d264c2-bc97-4313-bce0-737557312106@oracle.com>
Date: Wed, 6 Mar 2024 09:05:55 +0000
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 00/10] block atomic writes
To: Matthew Wilcox <willy@infradead.org>
Cc: axboe@kernel.dk, kbusch@kernel.org, hch@lst.de, sagi@grimberg.me,
        jejb@linux.ibm.com, martin.petersen@oracle.com, djwong@kernel.org,
        viro@zeniv.linux.org.uk, brauner@kernel.org, dchinner@redhat.com,
        jack@suse.cz, linux-block@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
        linux-fsdevel@vger.kernel.org, tytso@mit.edu, jbongio@google.com,
        linux-scsi@vger.kernel.org, ojaswin@linux.ibm.com, linux-aio@kvack.org,
        linux-btrfs@vger.kernel.org, io-uring@vger.kernel.org,
        nilay@linux.ibm.com, ritesh.list@gmail.com
References: <20240226173612.1478858-1-john.g.garry@oracle.com>
 <ZeembVG-ygFal6Eb@casper.infradead.org>
Content-Language: en-US
From: John Garry <john.g.garry@oracle.com>
Organization: Oracle Corporation
In-Reply-To: <ZeembVG-ygFal6Eb@casper.infradead.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?Yk5xeXB3TnFML1VReVFzMzhZZVNWTmtwcnZBYkY2ZzVBYXJmeGF3THFpR1lT?=
 =?utf-8?B?Mm9HeUxwcDRpR21lcXpnMXdRQUZRdFJKVmxVTllvaERYTmFXQ3hMQmNJZmh0?=
 =?utf-8?B?U2lZc2Z3U0JpOWd5UE5GVlc0Qml1aTVtaUE3Yi92MnM0UXM0dDJqWkk0b0VZ?=
 =?utf-8?B?TkFTN0VrSWc5a0NBSWNKSDJLbForejN1RkJyK0FqSjNQQ1l2VTJXWDNkcFZz?=
 =?utf-8?B?cldGd3k1Qm00cnNNVG1NNTNocDdjMnhpN0FGaGlaeHc0OCtObXMrVGc3am5E?=
 =?utf-8?B?THY2R2FIYjQvR3RDQUVRdFFXSkkwNU5VZVBUUjRtTncxV1F0c2pLTTFsWVVO?=
 =?utf-8?B?YWdONGpIc3dIVkM5SmUycXdxQWFwclc0N3BSTkNxOGFnWHhSZjBLdWZGTW05?=
 =?utf-8?B?ZGpFUmErUjQ2NzB4ZDlxaGlJUWlibUtKQ3RXMGc5bnQ1OVdlcWo3K3pmaGUr?=
 =?utf-8?B?TEhrcy9DcDVNTHJjMmVKZVp4QXlaQTZIVHZ0bXFReDVlczRQRk5jckNKVFpN?=
 =?utf-8?B?dlpyOWZ0WFJVR2xBYlZPVUs1TzN1ZjJwQ0QrcFpwaFRsWTJ3QzJzdDdTVWtP?=
 =?utf-8?B?dStQdmNEMGkvVWFzM3FKZ25IbkNaUlU0VERuQ283S2tVWDR1MFhnZlEyQjE2?=
 =?utf-8?B?a0RwY05meXphcGIxQ0I1ZWlnN1ZIaW1pTHNDdWNDRy9GcXl1Mm43cVpidm1D?=
 =?utf-8?B?Rm5Icy9Kd1R4YU9jNzE2RHBRelE3bnFFZ2ZlbnlOSTl6K09paUtrTCtaVzlt?=
 =?utf-8?B?VldjaVFITkpjS3VSbDdTLzN5eUJpV2FVMkRDeWpNczVJS2hNY21LbVZJLzdH?=
 =?utf-8?B?M2d6Q3FiL3hNVjNKdUw5NE1vNUdlWnZHNGlBSGdNTzRpZDhrUHk0K0pYMGMw?=
 =?utf-8?B?WWlGbjUzNzBOaGNtLzZuUnNEMmJnY3IzcCtkTmFrQkxPeDhwTHRXUDdyc3lt?=
 =?utf-8?B?WEU0TlY2OWxBRGErMFlOM0xhd25YdEdXak4rRlg0bEVURmQ1NFN2TisrblBq?=
 =?utf-8?B?OWI4UVJjemlRZVpRVDhKclMyWjFULzBqM0w4N29FQmNaN2U2WWMwOUh3SmVR?=
 =?utf-8?B?dnI0b1RLWXltVTc1bWhsUUk5WmRtRGJOMGFPRW5YbE8zZ3Y3T2ZweCtFemIw?=
 =?utf-8?B?blcwa1ZDcmhPcTg3Mkh6d2R4bjZIaFBoNWFzQ3FJZWoxSzB4aFdqVWxyTVBF?=
 =?utf-8?B?ai9QVWtaUjdMa2Z1MUZ4aFVNcU4vcm1TSVNlYTFxZFFySldZemVIZ3ZxdEFJ?=
 =?utf-8?B?Y2hqWWJ5dkN2dlZxWXJaUXRoUDZCVEFzS3F3bk5uZHRnN0VRVVRrR0hSZjdt?=
 =?utf-8?B?c2NLcEgxOUk4U3J4U0hLeG5pL3VTWTFhUUJDdVlVSk5WN254SUVpWE5NOFA3?=
 =?utf-8?B?ZmNwOWZFTlVKRnl5MmpXZlJvUVcvcmdFNFg0KzRndXlxcGVqTTBLODQ3a1Vx?=
 =?utf-8?B?RW9wN2M1M2ZlZ0NsQjd3UWsvRUd2dDJrZU9NL1BhRi9nVjRvamdTUWtqRXFp?=
 =?utf-8?B?TzY5NWJRem5mS1hjak92M1Blc0VxZm1NVnJmSGRQZnZPT2JRMklodGQrYkx0?=
 =?utf-8?B?R2E3eVlzRWNQTXZtOE5senlWZzNOMWM4dVdITnZkQnV0T2VOZGR1T0VhUHFx?=
 =?utf-8?B?d0ZaNDdHZGlpdTZBZUpmVWZ2aFFuVFk5YUtlREM3RHR3YWZzaFZEcmtsZmVP?=
 =?utf-8?B?M1dDSWFLdXg1NHRtSkFlanFpenllZkZrOW9HNCt5dDJlTWwzbHlrUFNsY2lS?=
 =?utf-8?B?ejdrZTlaNERGb2J1NmZsblM2cXplNEVGNkZGL3N1ZG5PSmdJTUNJNklGdE5h?=
 =?utf-8?B?VTZJSk1ab2xWY1VwY0dWV1pNZ1dtay83V3JTdGc5Y0VFS2k2aVZzTHNrNWFV?=
 =?utf-8?B?M0dtZFFLYkR3YTlPR0laSVoyK0lHUElKSWtmODhhNkFPWkM0REc4ci9MeHlS?=
 =?utf-8?B?NDk2NXZ5SHpyTTdwckZPOWZhS0lqdDY3THZ0WEtMY3hUczZybXZRalJPeWhO?=
 =?utf-8?B?UHVSOUNWMW0wSCtzdnV0aGVObkRBTGtmSVcreUM3cGhzeWdTUkdpdm82K2ky?=
 =?utf-8?B?S3BwTkV6VU5oMHBwY3F4eXRkY0dpbzE0ZDliVkhjaFc1ODkvSDRYYmlrUExL?=
 =?utf-8?B?aHp4RTBhalNSV1ZVaXJ6SHFSajdDaDc3cFU2cHpkTGhGRWJaKzBXREFhMTJk?=
 =?utf-8?B?UHc9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	gi0Duaej+reInOOWKPFDJwz1/dGT6wT67UmFD2I2MVyYF5E9JBExkRjbjw1LoCE1rVzBEaul/FuK6o7+4AkWc5LylebV/nCcLFDO9rY3iUrRuedPRAzAJ0ykgRoTOWKPEhq43U68hTanqFeVnr2EF+I2PbjQ7HHnqmAq+WiGraUFpAYMyKRp6PFPPcaDiM9ca47DDf7I4EVdI0iFX89c+bRtGfwSoEtNrPo0MNXUyaMPBuguyDITIXDMfxN9iGyDQYFrsrtmhYXNspz7syUWFRfUM+ULnZDiS2KfCQLV1luh/b4qQbcx1+Fe3wQNwRUWuMt5c/nCwnA4mJ1Aq9006W1JL9UUP2hvwC+LBed6kp4xHwQo9GRGt/04GMdgqQas5qm0DecwjjoLamoGM3axXtyR2wS8qqcJrkKE8E7dQdN+B+D/kF+DG7jo8xLlIVIq0t2XfGAkgoxdk+P8fZTrV04+WLZWaKseThdAwJtXKioHKjrGhXrXQU8EpmDe9e/9ico/5yWJm6ZWSaCRyJVbH/rpAYiR9nLYxmK4iU/l0yFbi4f1ecC1uogcxdBnTbiysQIqpxY8TpdNww0eJ9XXWRXLnflrDj0/yS3LrqJpmVM=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b0f1dd1-ed52-4cd0-a6fe-08dc3dbca51c
X-MS-Exchange-CrossTenant-AuthSource: DM6PR10MB4313.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2024 09:06:01.5335
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: WZengsZalc3F6NEVNX3o413pOcRg/Z71uaK6nfgTcBc4FDN6oaGVCz4pBOO5wnsONGbRmebBWHmQ0/V1FaO1Vg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR10MB7535
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-06_04,2024-03-05_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxlogscore=999
 adultscore=0 phishscore=0 spamscore=0 mlxscore=0 bulkscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2311290000 definitions=main-2403060071
X-Proofpoint-ORIG-GUID: PRoDzoCJsEyr8tsjjGxG8rn2LGpD2SBi
X-Proofpoint-GUID: PRoDzoCJsEyr8tsjjGxG8rn2LGpD2SBi

On 05/03/2024 23:10, Matthew Wilcox wrote:
> On Mon, Feb 26, 2024 at 05:36:02PM +0000, John Garry wrote:
>> This series introduces a proposal to implementing atomic writes in the
>> kernel for torn-write protection.
> 
> The API as documented will be unnecessarily complicated to implement
> for buffered writes, I believe.  What I would prefer is a chattr (or, I
> guess, setxattr these days) that sets the tearing boundary for the file.
> The page cache can absorb writes of arbitrary size and alignment, but
> will be able to guarantee that (if the storage supports it), the only
> write tearing will happen on the specified boundary.

In the "block atomic writes for XFS" series which I sent on Monday, we 
do use setxattr to set the extent alignment for an inode. It is not a 
tearing boundary, but just rather effectively sets the max atomic write 
size for the inode. This extent size must be a power-of-2. From this we 
can support atomic write sizes of [FS block size, extent size] for 
direct IO.

For bdev file operations atomic write support in this series for direct 
IO, atomic write size is limited by the HW support only.

> 
> We _can_ support arbitrary power-of-two write sizes to the page cache,
> but if the requirement is no tearing inside a single write, then we
> will have to do a lot of work to make that true.  It isn't clear to me
> that anybody is asking for this; the databases I'm aware of are willing
> to submit 128kB writes and accept that there may be tearing at 16kB
> boundaries (or whatever).

In this case, I would expect the DB to submit 8x separate 16KB writes. 
However if we advertise a range of supported sizes, userspace is 
entitled to use that, i.e. they could submit a single 128kB write, if 
supported.

As for supporting buffered atomic writes, the very simplest solution for 
regular FS files is to fix the atomic write min and max size at the 
extent size, above. Indeed, that might solve most or even all usecases. 
This is effectively same as your idea to set a boundary size, except 
that userspace must submit individual 16KB writes for the above example. 
As for bdev file operations, extent sizes is not a thing, so that is 
still a problem.

Having said all this, from discussion "[LSF/MM/BPF TOPIC] untorn 
buffered writes", I was hearing that can use a high-order for RWF_ATOMIC 
data and it would be just a matter of implementing support in the page 
cache, like dealing with already-present overlapping smaller folios - is 
implementing this now the concern?

Thanks,
John