On Wed, 13 Dec 2023, Christian Brauner wrote:
> On Wed, Dec 13, 2023 at 08:46:54AM +1100, NeilBrown wrote:
> > On Wed, 13 Dec 2023, Miklos Szeredi wrote:
> > > On Tue, 12 Dec 2023 at 16:35, Kent Overstreet
> > > wrote:
> > >
> > > > O
On Wed, 13 Dec 2023, Dave Chinner wrote:
> On Wed, Dec 13, 2023 at 09:31:13AM +1100, NeilBrown wrote:
> > On Wed, 13 Dec 2023, Dave Chinner wrote:
> > >
> > > What you are suggesting is that we now duplicate filehandle encoding
> > > into every filesystem's s
On Wed, 13 Dec 2023, Kent Overstreet wrote:
> On Wed, Dec 13, 2023 at 09:57:22AM +1100, NeilBrown wrote:
> > On Wed, 13 Dec 2023, Kent Overstreet wrote:
> > > On Mon, Dec 11, 2023 at 11:40:16PM +, David Howells wrote:
> > > > Kent Overstreet wrote:
> >
gt; statx? I'm wondering if the userspace side was thought through, I'm
> sure glibc people will have something to say.
The man page says:
Therefore, do not simply set mask to UINT_MAX (all bits set), as
one or more bits may, in the future, be used to specify an
extension to the buf
On Wed, 13 Dec 2023, Dave Chinner wrote:
> On Wed, Dec 13, 2023 at 08:57:43AM +1100, NeilBrown wrote:
> > On Wed, 13 Dec 2023, Dave Chinner wrote:
> > > On Tue, Dec 12, 2023 at 09:15:29AM -0800, Frank Filz wrote:
> > > > > On Tue, Dec 12, 2023 at 10:1
lesystem need to be changed.
NeilBrown
hat can be modified needs to use a different
> interface - one that has a corresponding "set" operation.
stx_size, stx_mtime, stx_atime, stx_mode, stx_owner, stx_group,
stx_nlink,
These can all be modified but don't have matched get and set operations.
stx_handle, of course, cannot be modified.
I think I must be completely misunderstanding you, because the way I
read your words, they don't make any sense at all. Help!
NeilBrown
for the inclusion of the flag it is, I
think, a clear indication that "would not help" is what our fact
checkers would call "over-reach".
NeilBrown
>
> What would help, if said software started using a unique identifier.
> We already seem to have a unique ID in the form of fi
On Tue, 12 Dec 2023, Kent Overstreet wrote:
> On Tue, Dec 12, 2023 at 11:59:51AM +1100, NeilBrown wrote:
> > On Tue, 12 Dec 2023, Kent Overstreet wrote:
> > > NFSv4 specs that for the maximum size? That is pretty hefty...
> >
> > It is - but it needs room to identi
On Tue, 12 Dec 2023, Kent Overstreet wrote:
> On Tue, Dec 12, 2023 at 10:53:07AM +1100, NeilBrown wrote:
> > On Tue, 12 Dec 2023, Kent Overstreet wrote:
> > > On Tue, Dec 12, 2023 at 09:43:27AM +1100, NeilBrown wrote:
> > > > On Sat, 09 Dec 2023, Kent Overstreet w
On Tue, 12 Dec 2023, Kent Overstreet wrote:
> On Tue, Dec 12, 2023 at 09:43:27AM +1100, NeilBrown wrote:
> > On Sat, 09 Dec 2023, Kent Overstreet wrote:
> > > On Fri, Dec 08, 2023 at 12:34:28PM +0100, Donald Buczek wrote:
> > > > On 12/8/23 03:49, Kent Overstree
number by filling in bits from
the fs-inode number from one end, and bits from the volume number from
the other end, then you don't need to pre-configure how the 64 bits are
shared.
You record inum-bits and volnum bits in the filesystem metadata, and
increase either as needed. Once the sum hits 64, you start returning
ENOSPC for new files or new volumes.
There will come a day when 64 bits is not enough for inodes in a single
filesystem. Today is not that day.
NeilBrown
On Fri, 08 Dec 2023, Kent Overstreet wrote:
> On Fri, Dec 08, 2023 at 12:16:53PM +1100, NeilBrown wrote:
> > On Thu, 07 Dec 2023, Donald Buczek wrote:
> > >
> > > I'd vote for the subvol-id. I think, with bcachefs a u32 would do,
> > > but it could be retu
solve all the problems caused by the
addition of a volume/subvol level between "filesystem" and "inode".
Thanks,
NeilBrown
On Wed, 06 Dec 2023, Donald Buczek wrote:
> On 12/4/23 23:45, NeilBrown wrote:
>
> >> Hmm, isn't a (struct file_handle) filehandle supposed to be opaque?
> >> I'm not sure if it is a good idea to stick filesystem-specific
> >> meta-information (like a subvolume i
On Mon, 04 Dec 2023, Donald Buczek wrote:
>
> On 11/30/23 21:37, NeilBrown wrote:
> > On Thu, 30 Nov 2023, Kent Overstreet wrote:
> >> On Thu, Nov 30, 2023 at 08:35:12AM +0100, Donald Buczek wrote:
> >>> On 11/29/23 22:43, Kent Overstreet wrote:
> >>&
leave enough bits to shard inode numbers at create time based
> > > on CPU id, which isn't the _most_ important optimization, but would hurt
> > > to lose.
> > >
> > > Going forward, we really need - as you allude to - better userspace
> > > APIs. Inode
of
name_to_handle_at().
Experience with NFSv2 and exclusive opens shows that if a filesystem
breaks something in a way that it still works most of the time but
occasionally still fails randomly, then people will still use it
(providing it provides real benefits of course) and they will find a
work-around to avoid the breakage. So thanks to NFSv2, people stopped
using O_CREAT|O_EXCL as a locking mechanism, and did things with hard
links instead.
NeilBrown
18 matches
Mail list logo
