From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) (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 3D40113777E for ; Sun, 19 Apr 2026 21:35:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.217.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776634559; cv=none; b=nfrshHIlTVFI7yQZuadoD+IxN6+UV+sfKKgwkszhSkvNXJprvdIexe5EGzafSxccFmFfLfSBErdHW2oNFHHwbIeAC5CYmZ9FQjh7lKewRkHsR16eVjyXf1mA5t4LHLiC8gGHcXf8N4ScKEFdoAAPm7OT1puIhWvv4oIKRkpUOG0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776634559; c=relaxed/simple; bh=IDBG0Tx2qhEbmiaoQgRUl605w3K/SNfVuGM+OVcU3EY=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=exkT4jojpQpiXLWXY5yPK6Lc705f3beq3/Vm/rRMXOn5gghvxDpFKMVVL9HdTRehoQ3GnzHr8cz+kEqgIhmKI7pvC3ThwiDyA/Tq0w5t7qD8O2T5dC/VRd/0bSrkOoypk7Lf71SC1JIA+dQNdJ3N37WYnQT9eNJ5Ht9T1+rG12M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Qs6mUNAS; arc=none smtp.client-ip=209.85.217.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Qs6mUNAS" Received: by mail-vs1-f41.google.com with SMTP id ada2fe7eead31-605def5b80cso731183137.2 for ; Sun, 19 Apr 2026 14:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776634557; x=1777239357; darn=vger.kernel.org; h=content-transfer-encoding:content-disposition:mime-version :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=crRQmQHyg4MxT/wLW9vc4SYD3U+N/wKd83cupDhzFY0=; b=Qs6mUNASNoOocOBj7IS86OLPnbAFUIdNzkpCXwIQRNW0+9BDgNxhY4DltunEgOhKG1 9+tLrrXWRXmyz8OVOuP0TqevNqfdhGO+XAzhuoQRVxPSrbII+rN4xpehn46ejwiJCmFR 58QEU37fJiBklhPxgIDDAN1sRbe+GlHFBQQGCnmdlSGK+MQqGXdvYMMsbPgfq6ont3Tz StnrZAppNoydIFAQ49rYyxOV3jFwATQP+slWUsKOB3zAIy34s32nnSkLIJgdI3/aytzM c20+ewWGhEg7mIMh4w/PVakhcy5uy8ucgm4RwacUOx7Nuedcb5pqMPQw6gGitgyiqmV+ mV/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776634557; x=1777239357; h=content-transfer-encoding:content-disposition:mime-version :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=crRQmQHyg4MxT/wLW9vc4SYD3U+N/wKd83cupDhzFY0=; b=h18u0qPg5NK+pu/JohqbMz8sA5pmQkvwrm1An0ihoJcCxPuWZn9Pq32BlRQ1yWRIOK 37yHnigG35I0YMtYd+7gc7CmpJlQrTspkGQbsUIJQsnl+/iKbrw9oUxdc3ANwU1k1e5I gzdaH5YZ3bY6ngTbsOufxg9CKS0nbFXMkNVrN/iO+XPoPGZB9oVV1LPfCYCu09KwDTor B9JT43PdcDaDyzwOMB3Wq6cnjRnqx9/Oe87mkxa4wGNUL582P75qGM2l9UwyqU4gL52o tE9slf7K6irIegD5pEHm3Z7p/kqgtyUG7oQ2a5pHiHZDC6D5P+Qaz07z/5S4B343ExC5 tIsQ== X-Gm-Message-State: AOJu0Yz82qpNntKwmZziFuBJsjjjgRxKC1QATZzUN/Lo8b12DIE5pItr ojDkLuDcfwT44zdEcD0iwGIlpqrClHnn5N4KK0O0Q05E/cMVRmzDtb0fA8eMtUOr X-Gm-Gg: AeBDiet8fVzuBkkgGfsZZW1C5RmejxzaJYpp9V5NYyKdo9KqB9paA9F2ewG4EqcnMC2 escjSHbevA5oJc3DiY0cv8evTEVGYXb/ZiEhHPCHu8sAGubEKFgcgcyqFPBEOgkGJvpG0JPyEZg VHax+oNPA54cd2kWVfpzHlTYJlqHzUmyfyPc6WBxDw8hc8jdJetAArZOojvHWQ399efWul0AWH2 F/Nw6GedUqtcd/8SsUj7ZmvnVBdwrt1cVNtXnI4V6I/lhuPItrueTqKmt3dLXDh9OVR0iL3TV4U wDjgPqpJve7rpbbVdS7YucupUg+EjdegMMci7FmrUwKfAVEUWSO5pEHSyR1r2nKoFTL4qaNr2pf 3kF0Ng+n2TLBF5Vm0FEjoa3ixdpqWXwmORJ9ROa572LAzDZ+i13gAPYZwG1Yl8na+8stXRpeDFC jhERGgAS895ptetzGc/8esHKKzerlXspXdjNjGz4BmVXQ770XDD4RsBRMwzbDztEew90ta6qVwC zWnIXQ9aNV6W31sOuwjbATAtKIVEoUaOg7L63X38SqG9z5Mi0u5XkdSO5xcZQI= X-Received: by 2002:a05:6102:3f86:b0:607:7991:f02e with SMTP id ada2fe7eead31-616f8392189mr3715182137.26.1776634556986; Sun, 19 Apr 2026 14:35:56 -0700 (PDT) Received: from localhost (host63.190-224-190.telecom.net.ar. [190.224.190.63]) by smtp.gmail.com with UTF8SMTPSA id ada2fe7eead31-617455b52bcsm3948901137.3.2026.04.19.14.35.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2026 14:35:56 -0700 (PDT) Date: Sun, 19 Apr 2026 18:35:53 -0300 From: Esteban Cerutti To: linux-kernel@vger.kernel.org Cc: linux-block@vger.kernel.org, linux-nvme@lists.infradead.org Subject: [RFC] block/nvme: exploring asynchronous durability notification semantics Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hi Hannes, Christoph, thank you both for the detailed replies. They were very helpful and corrected several misconceptions on my side. In particular, I now understand that: - reliance on synchronous flushes is not universal and largely depends on filesystem design (e.g. ext4 vs btrfs), - FUA already provides a per-request durability guarantee when needed, - and that power-backed guarantees at the system level are much harder to make reliable than they may appear. Based on your feedback, I took some time to read more about how this problem is handled in practice, especially at the filesystem and database level (e.g. journaling, WAL, group commit, batching of fsync). It seems that the cost of durability in fsync-heavy workloads is indeed well known, but is typically addressed at higher layers rather than in the block layer or device interface. So rather than defending my original idea, I would like to refine the question. Is there a fundamental reason why these optimizations are handled exclusively at the filesystem / application level, instead of being exposed (or assisted) at a lower level such as the block layer or device interface? For example, is it due to: - lack of reliable visibility into device-internal persistence state, - difficulty in defining correct semantics across different hardware, - or simply that higher layers already have enough information to optimize safely (making lower-level support unnecessary)? I realize that my earlier proposal likely underestimated the complexity involved, but I am still trying to understand whether there is a meaningful limitation at the lower layers, or if this is primarily a question of where the problem is best solved. Thanks again for your time and for the insights — this has already been very useful for understanding how these pieces fit together. Best regards, Esteban