From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6645B3195E7 for ; Wed, 29 Oct 2025 21:23:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761773021; cv=none; b=UMFAh0wkvA340b2ZMoqpjoE/dV/k6P+wHlxXY5wgcqNhgnIqJAiovwi0JHL0TDp6y1ZbQJwRCI/h9gN3UDpZU7G44Umfs2HkFQEDMvDBTScyN0kNk1VgMEUIyCokucJ5QAMZPnEGxFl8W5/nbt+ClCkTnCeaWBTfW+WUyaNtLaw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761773021; c=relaxed/simple; bh=Q8GbFpKZ0G2WK3boaHgt/WIjta7Wgy2yicNjI9IW2zs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=V0Yh24ju2XScdhnWAZ2El33/jN/Ox0YyydnDWwJ0IVL3mAL4+peLjuenBe0CHoyTNoiD20sOsOoZFV63KJua5+Z70qox1ELLknV3rzleUmMjnUffutrLiGhSonYIi4ybcMxg9kR4wnSAjLra5QyuDqxoAz4QJJ3NgquvWmc5kSU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=Lhi4nY7m; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="Lhi4nY7m" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-427015003eeso269013f8f.0 for ; Wed, 29 Oct 2025 14:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1761773018; x=1762377818; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=pTUPsF7Fte/AGInCGPT8Bm06cRTL6FI2Yd2BduEa3rQ=; b=Lhi4nY7mE1VKGUIUe7MMOYx3vwfyb6bQKJi06EWO7qIIMxMobGFA6FoW5ZEE3pgX50 sM145QJkripClJTk67gkYqNmwgRuVFelnnuNxatUMdMQHFwIYCOnh0J9/ywJ69/52sjb pDQ5XLuS05q4hZh50K4/87jw6GEtgk3UvyJk3NAxZS8zcoGnByseefsUyTU48e4pN2zA Kqem8znipIdYalxSf8ePbKh+lDpl/pyRjso98IFsZo3qIkcCRicik7m7HolQ8nU90oSD As5LJDjFf/bBpJoeMCFxzmJ3WZ+xcd/slEusVnTyORw5Y1Zg0qS1rQfg7NN1/4+XXMo2 0JpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761773018; x=1762377818; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pTUPsF7Fte/AGInCGPT8Bm06cRTL6FI2Yd2BduEa3rQ=; b=R3VEzAOwXd8gknoj4ZK4Abc10mAr24KfQ/M+8ZBJn4milZEKVybnrtxR1lPeStQJiR uETWgzGJf2CveBIGwdTjFrmQQNP7wEcxGd3gK9YzVpBtfg5QKDFBEptQ1ivmGJkUdmVu 1xoWJmDJNb/Y7NnzlX2d+wUl9sxtoUW5WR/ZG/e6FdKKTYsUKoRzucA9uzh5QnzqeRHj 5/QdaoUkqYHDveC1M37UsPM54UokXwTftuZVmRyy7Gdp2EGomF/VkWyRZZYrXfzRmnZT S+9UNrGXJxlICRB5S8L1KDtNarZiAzVHRnwuO8SRpota8/8/z37p8cPh3xGm32TC8AmJ jkrQ== X-Forwarded-Encrypted: i=1; AJvYcCWVa8Iuj1ebOQis9j4ttZUF5BECF0/vueP5JVYyYqSYeCtk8t7tDOl/LnGyHBD492V40ITjgXukKL4=@vger.kernel.org X-Gm-Message-State: AOJu0Yw0aO+HJX7d7jlmWssALYcDDlLKc1RM+Y5GFFww5CSoW3VDkzYR 1Vb8DRPVog3NCDgogHrIFxxT+wsyEJn5yDxGifx8gejRo/gxosN7lWZogVnfB9mdq1g= X-Gm-Gg: ASbGncsxYV/4EEIwb2VbM6ipYgZddK0SQLNPa30PatF8kToK6F6UF0xfG/dEXjDXufZ uTcTD17VE/dJ/yePFLUUzuXIo4e9CmsLLzWMS5S5jmBdB+M6tltPhKSDu7CIZpJL331HaEj+aW/ f+xyQyjvHzbTwOK7ewbekSGZHSKZ6K2bh0sZ/a/Z8YweJaC8png7NvXlqq9kP15eqt8rEJO6A+w P0jktxFOkzVIK2FsfqBgeKmYoasbzwOrfAFZPeIxNNTUords63heM5nWk2E32yvdFRZ9+x31lhQ BMbq3GXySeMEweqnOKIOwSKf1YVQPq6QzumW6rfBrODpcBkDdzRyjTWY1btj27kpHdDWhTWyUCM cc1EK5bSrRGOandWNFDkHfkiff++YiFudXs9mui28C2Hc+ZTM2VOXzf7eHk9iI5amQz7hySDrmK ZI4W+HVM953IzTHZuPpsdowO2L3pUZ X-Google-Smtp-Source: AGHT+IFWiY+tTPVyw5FGPKRDc6cNk4FAtKyr7K6bwTWppv+W/Z3W2oVYRb1tD5oyBMeW0DnOYj0IDg== X-Received: by 2002:a05:6000:2088:b0:3e6:f91e:fa72 with SMTP id ffacd0b85a97d-429aef7355amr2706394f8f.7.1761773017473; Wed, 29 Oct 2025 14:23:37 -0700 (PDT) Received: from ?IPV6:2403:580d:fda1::299? (2403-580d-fda1--299.ip6.aussiebb.net. [2403:580d:fda1::299]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-29498d097fasm161757355ad.29.2025.10.29.14.23.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Oct 2025 14:23:36 -0700 (PDT) Message-ID: <8f384c85-e432-445e-afbf-0d9953584b05@suse.com> Date: Thu, 30 Oct 2025 07:53:30 +1030 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/4] xfs: fallback to buffered I/O for direct I/O when stable writes are required To: Christoph Hellwig , "Darrick J. Wong" Cc: Carlos Maiolino , Christian Brauner , Jan Kara , "Martin K. Petersen" , linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-raid@vger.kernel.org, linux-block@vger.kernel.org, linux-btrfs@vger.kernel.org References: <20251029071537.1127397-1-hch@lst.de> <20251029071537.1127397-5-hch@lst.de> <20251029155306.GC3356773@frogsfrogsfrogs> <20251029163555.GB26985@lst.de> Content-Language: en-US From: Qu Wenruo Autocrypt: addr=wqu@suse.com; keydata= xsBNBFnVga8BCACyhFP3ExcTIuB73jDIBA/vSoYcTyysFQzPvez64TUSCv1SgXEByR7fju3o 8RfaWuHCnkkea5luuTZMqfgTXrun2dqNVYDNOV6RIVrc4YuG20yhC1epnV55fJCThqij0MRL 1NxPKXIlEdHvN0Kov3CtWA+R1iNN0RCeVun7rmOrrjBK573aWC5sgP7YsBOLK79H3tmUtz6b 9Imuj0ZyEsa76Xg9PX9Hn2myKj1hfWGS+5og9Va4hrwQC8ipjXik6NKR5GDV+hOZkktU81G5 gkQtGB9jOAYRs86QG/b7PtIlbd3+pppT0gaS+wvwMs8cuNG+Pu6KO1oC4jgdseFLu7NpABEB AAHNGFF1IFdlbnJ1byA8d3F1QHN1c2UuY29tPsLAlAQTAQgAPgIbAwULCQgHAgYVCAkKCwIE FgIDAQIeAQIXgBYhBC3fcuWlpVuonapC4cI9kfOhJf6oBQJnEXVgBQkQ/lqxAAoJEMI9kfOh Jf6o+jIH/2KhFmyOw4XWAYbnnijuYqb/obGae8HhcJO2KIGcxbsinK+KQFTSZnkFxnbsQ+VY fvtWBHGt8WfHcNmfjdejmy9si2jyy8smQV2jiB60a8iqQXGmsrkuR+AM2V360oEbMF3gVvim 2VSX2IiW9KERuhifjseNV1HLk0SHw5NnXiWh1THTqtvFFY+CwnLN2GqiMaSLF6gATW05/sEd V17MdI1z4+WSk7D57FlLjp50F3ow2WJtXwG8yG8d6S40dytZpH9iFuk12Sbg7lrtQxPPOIEU rpmZLfCNJJoZj603613w/M8EiZw6MohzikTWcFc55RLYJPBWQ+9puZtx1DopW2jOwE0EWdWB rwEIAKpT62HgSzL9zwGe+WIUCMB+nOEjXAfvoUPUwk+YCEDcOdfkkM5FyBoJs8TCEuPXGXBO Cl5P5B8OYYnkHkGWutAVlUTV8KESOIm/KJIA7jJA+Ss9VhMjtePfgWexw+P8itFRSRrrwyUf E+0WcAevblUi45LjWWZgpg3A80tHP0iToOZ5MbdYk7YFBE29cDSleskfV80ZKxFv6koQocq0 vXzTfHvXNDELAuH7Ms/WJcdUzmPyBf3Oq6mKBBH8J6XZc9LjjNZwNbyvsHSrV5bgmu/THX2n g/3be+iqf6OggCiy3I1NSMJ5KtR0q2H2Nx2Vqb1fYPOID8McMV9Ll6rh8S8AEQEAAcLAfAQY AQgAJgIbDBYhBC3fcuWlpVuonapC4cI9kfOhJf6oBQJnEXWBBQkQ/lrSAAoJEMI9kfOhJf6o cakH+QHwDszsoYvmrNq36MFGgvAHRjdlrHRBa4A1V1kzd4kOUokongcrOOgHY9yfglcvZqlJ qfa4l+1oxs1BvCi29psteQTtw+memmcGruKi+YHD7793zNCMtAtYidDmQ2pWaLfqSaryjlzR /3tBWMyvIeWZKURnZbBzWRREB7iWxEbZ014B3gICqZPDRwwitHpH8Om3eZr7ygZck6bBa4MU o1XgbZcspyCGqu1xF/bMAY2iCDcq6ULKQceuKkbeQ8qxvt9hVxJC2W3lHq8dlK1pkHPDg9wO JoAXek8MF37R8gpLoGWl41FIUb3hFiu3zhDDvslYM4BmzI18QgQTQnotJH8= In-Reply-To: <20251029163555.GB26985@lst.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 在 2025/10/30 03:05, Christoph Hellwig 写道: > [Adding Qu and the btrfs list] > > On Wed, Oct 29, 2025 at 08:53:06AM -0700, Darrick J. Wong wrote: >>> + if (mapping_stable_writes(iocb->ki_filp->f_mapping)) { >>> + xfs_info_once(mp, >>> + "falling back from direct to buffered I/O for write"); >>> + return -ENOTBLK; >>> + } >> >> /me wonders if the other filesystems will have to implement this same >> fallback and hence this should be a common helper ala >> dio_warn_stale_pagecache? But we'll get there when we get there. > > As far as I'm concerned they should. Btrfs in fact has recently done > that, as they are even more exposed due to the integrated checksumming. > > So yes, a common helper might make sense. Especially if we want common > configuration for opt-outs eventually. Yep, a common helper will help, or even integrate the check into __iomap_dio_rw(). Although btrfs currently uses some btrfs specific flags to do the check, we're also setting stable writes flags for the address space, thus we can share the same check. However I'm not sure if a warning will be that useful. If the warning is only outputted once like here, it doesn't show the ino number to tell which file is affected. If the warning is shown every time, it will flood the dmesg. It will be much straightforward if there is some flag allowing us to return error directly if true zero-copy direct IO can not be executed. Thanks, Qu > >>> file->f_mode |= FMODE_NOWAIT | FMODE_CAN_ODIRECT; >>> - file->f_mode |= FMODE_DIO_PARALLEL_WRITE; >>> - if (xfs_get_atomic_write_min(XFS_I(inode)) > 0) >>> - file->f_mode |= FMODE_CAN_ATOMIC_WRITE; >>> + if (!mapping_stable_writes(file->f_mapping)) { >>> + file->f_mode |= FMODE_DIO_PARALLEL_WRITE; >> >> Hrm. So parallel directio writes are disabled for writes to files on >> stable_pages devices because we have to fall back to buffered writes. >> Those serialize on i_rwsem so that's why we don't set >> FMODE_DIO_PARALLEL_WRITE, correct? > > Yes. > >> There's not some more subtle reason >> for not supporting it, right? > > Not that I know of anyway. >