From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (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 BF918250EC for ; Wed, 9 Apr 2025 01:34:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744162486; cv=none; b=UO2ToPfBJ4ZWehoHlsktpcrXWVzPBKjAwe0HtrIcK4gFSVRArOFSeyokrylVCK/7jR9x5Bs7oQ4MW7ErVXJCAi/JfGqlbQMU0hpbSTe5c2OSQ6/nRaqcgS8DSsDLJGqSB6K2YHzVPgU4xxfhF1NnfykvLTGOSGFGoTFNPGqhHc4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744162486; c=relaxed/simple; bh=oeG+4HAagfYJR67bmiU5uGwhjpjwSraicPyYZz+OtWU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=vEwYOacRXDg5kyRvKPGTWz6vhOK4IgJPNX5THY9NVPNoaGj4jGllMywEt9xX0tN+n+WstKPHJ35uLA3zo8uiVTsYUAyY0joaT9M+kgSJD85ig7CguJ0MNNhSwj6eG0e1a3YDRrAdQQALj9rdAMip5OgXIctsULo6Sg1dRtJcA4w= 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=WgBNXcQ/; arc=none smtp.client-ip=209.85.210.178 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="WgBNXcQ/" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-736c1cf75e4so5377943b3a.2 for ; Tue, 08 Apr 2025 18:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744162484; x=1744767284; darn=lists.linux.dev; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=3gWW7mQrB9d+AnX17ft9zAf82G6HqoBmSe5FjNlAnCs=; b=WgBNXcQ/rtwbbp5b/qsUFuacOm4i9lR69uonIOaGJWtYIJy0PfUSbSYZLK5CtLY0hR yFyBYwSszkZ1xTRP8Go6usSW2FgZZVmNEL5UFircDWwW3QdauoG8Ctj8JeUdtUO12/Xa 772wP6R6/Fjt4XexcTeiATdh5y6Nai1DpM/vCmlqiWuvPW70O5F5tI2g6E5fCJAXxgGJ n7cY565CCLpEBHC4kCdymk+lYOpeGvikGtYcXKO3pw8NAMRMExyi0cN/CHzo/64cFPez D8/vxhuqDPGBmJtICJRRSJWeqpgtfiwqpWgvCgKE7fpmaOvn54A6rE+0RrCr95eSurE5 /BsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744162484; x=1744767284; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3gWW7mQrB9d+AnX17ft9zAf82G6HqoBmSe5FjNlAnCs=; b=CFaJGGVIzr4BjzsW5OT4DJWhPqxOb4d0l15L8U+e7FBOJFXax22L5epfm0vADBPQd8 yIeg301woEiMiWohQjO1gBFaUctYES/yUKG7ZJ80EFCvXW+Z+aucmOYo78b2LFdG7nPn iNoq/ioLfZcLWNQ4b/Z9dqiLhI8+ARyo0eBXR4PpAYHX9vYzGLmOrXbUwfMjr1PKTMNV XsY5F5kwkmRYqfmZhFYiJXSyBNFi3lNr//vmrz94pnxz/kE+CorqbGp4Bq/rc1k7gJAh FWJqmsXIj8WBizGXh51Bj01n+orChjBTJADnGxwXsrPDMMWaj9IWja0WeNaQFyZOx6Nk WbSg== X-Forwarded-Encrypted: i=1; AJvYcCVOyRIllAdwtEs79YivQtBHLW9IrCM52774UeEkXV4zznW8bJu0DUZ13j4kLdF5W9FMZOwvww==@lists.linux.dev X-Gm-Message-State: AOJu0Yx5VbxRVhmDFqXAFo0RCSkuUaCp1SJIyzSfUbEOazIMFzQpH6ZE iia/a9iIFQLdGS7wYZAnb6PzmSS5bTvqV+/LtRsR5OXWLNgilIC/ X-Gm-Gg: ASbGncsdj+XVPUUdxyzuCokgF24ae+p8hTWqYlUSXXcrS1pWedaO3/SIb9yPU9rHn1C BN9BRfRgcxLCwCSqfl/bwv4iNm8nln1Knx6iy7bQuSdcL4di439LnfmZd/pzVC+w/8cGvm2a08U v6zpCutMs23R245Gbxs9RxFo5VPse3lY8dOojGBHiEmgBM9vfwSvoB0+MToiFNbpeUGkU17tIgR slF+pLWIgXj3PsX534waVHh0xVvHKshxekcCTL2GF1by2rxM2EyOz8zZa76sZ4VbLJ3+dbm1cWM YusNPOTiYDWBtnF0ymDTuBH/StIu/OK92ObJCdy1++YzwvpDQMqcGkI= X-Google-Smtp-Source: AGHT+IE3yPMa/eAyrcIcKnygKFejo73k37164uoaXWheqCJIVO7kLvZ6j6r+yahYkE1fLzUTtnx2sQ== X-Received: by 2002:a05:6a00:1484:b0:736:4d44:8b77 with SMTP id d2e1a72fcca58-73bae4b3d15mr1532729b3a.8.1744162483721; Tue, 08 Apr 2025 18:34:43 -0700 (PDT) Received: from archie.me ([103.124.138.155]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-73bb1d2b108sm55039b3a.19.2025.04.08.18.34.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Apr 2025 18:34:42 -0700 (PDT) Received: by archie.me (Postfix, from userid 1000) id 0FFEF4236D23; Wed, 09 Apr 2025 08:34:39 +0700 (WIB) Date: Wed, 9 Apr 2025 08:34:39 +0700 From: Bagas Sanjaya To: David Howells , Christian Brauner Cc: Paulo Alcantara , Jeff Layton , Viacheslav Dubeyko , Alex Markuze , Timothy Day , Jonathan Corbet , netfs@lists.linux.dev, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] netfs: Update main API document Message-ID: References: <1565252.1744124997@warthog.procyon.org.uk> Precedence: bulk X-Mailing-List: netfs@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cxzS9cWmxd0BSJ70" Content-Disposition: inline In-Reply-To: <1565252.1744124997@warthog.procyon.org.uk> --cxzS9cWmxd0BSJ70 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 08, 2025 at 04:09:57PM +0100, David Howells wrote: > + * For writeback, it is unknown how much there will be to write until the "... will be written ..." > + pagecache is walked, so no limit is set by the library. > ... > +Further, if a read from the cache fails, the library will ask the filesy= stem to > +do the read instead, renegotiating and retiling the subrequests as neces= sary. Read from the filesystem itself or direct read? > +When writeback occurs, folios that are so marked will only be written to= the > +cache and not to the server. Writeback handles mixed cache-only writes = and > +server-and-cache writes by using two streams, sending one to the cache a= nd one > +to the server. The server stream will have gaps in it corresponding to = those "... and another to the server." > +folios. > + > ... > +Netfslib will pin resources on an inode for future writeback (such as pi= nning > +use of an fscache cookie) when an inode is dirtied. However, this needs > +managing. Firstly, a function is provided to unpin the writeback in inode management? > +``->write_inode()``:: > =20 > ... > +The fields generally of interest to a filesystem are:: > =20 > struct netfs_io_request { > + enum netfs_io_origin origin; > struct inode *inode; > struct address_space *mapping; > - struct netfs_cache_resources cache_resources; > + struct netfs_group *group; > + struct netfs_io_stream io_streams[]; > void *netfs_priv; > - loff_t start; > - size_t len; > - loff_t i_size; > - const struct netfs_request_ops *netfs_ops; > + void *netfs_priv2; > + unsigned long long start; > + unsigned long long len; > + unsigned long long i_size; > unsigned int debug_id; > + unsigned long flags; > ... > }; > =20 > -The above fields are the ones the netfs can use. They are: > +They are: "These fields are, in detail:" > ... > +The stream struct looks like:: "The stream struct is defined as::" > + > + struct netfs_io_stream { > + unsigned char stream_nr; > + bool avail; > + size_t sreq_max_len; > + unsigned int sreq_max_segs; > + unsigned int submit_extendable_to; > + ... > + }; > + > ... > +The table starts with a pair of optional pointers to memory pools from w= hich > +requests and subrequests can be allocated. If these are not given, netf= slib > +has default pools that it will use. If the filesystem wraps the netfs s= tructs "... it will use instead." > +in its own larger structs, then it will need to use its own pools. Netf= slib > +will allocate directly from the pools. > =20 > ... > + This is not permitted to return an error. In the event of failure, > + ``netfs_prepare_write_failed()`` must be called. "This method is not permitted to return an error. Instead, in the event of failure, ..." Thanks. --=20 An old man doll... just what I always wanted! - Clara --cxzS9cWmxd0BSJ70 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSSYQ6Cy7oyFNCHrUH2uYlJVVFOowUCZ/XOqgAKCRD2uYlJVVFO oxwDAQCIp2Z67CrtkEI2vxhnwb/3m5aDgDDO7eFv+9qsvmRlTQD9GbhobtuuelYe u6w0SgAN6bt+eNQLl6cm97wW0cB66A8= =TxHk -----END PGP SIGNATURE----- --cxzS9cWmxd0BSJ70--