On Wed, 2020-08-05 at 09:43 +0200, Miklos Szeredi wrote:
> On Wed, Aug 5, 2020 at 3:54 AM Ian Kent wrote:
> > > > It's way more useful to have these in the notification than
> > > > obtainable
> > > > via fsinfo() IMHO.
> > >
> > > What is it useful for?
> >
> > Only to verify that you have seen
On Wed, Aug 5, 2020 at 1:36 PM Ian Kent wrote:
>
> I can see in the kernel code that an error is returned if the message
> buffer is full when trying to add a message, I just can't see where
> to get it in the libmount code.
>
> That's not really a communication protocol problem.
>
> Still I need
On Wed, Aug 5, 2020 at 3:54 AM Ian Kent wrote:
>
> > > It's way more useful to have these in the notification than
> > > obtainable
> > > via fsinfo() IMHO.
> >
> > What is it useful for?
>
> Only to verify that you have seen all the notifications.
>
> If you have to grab that info with a separat
On Tue, 2020-08-04 at 15:19 +0200, Miklos Szeredi wrote:
> On Tue, Aug 4, 2020 at 1:39 PM Ian Kent wrote:
> > On Mon, 2020-08-03 at 11:29 +0200, Miklos Szeredi wrote:
> > > On Thu, Jul 23, 2020 at 12:48 PM David Howells <
> > > dhowe...@redhat.com>
> > > wrote:
> > >
> > > > > > _
On Tue, Aug 4, 2020 at 1:39 PM Ian Kent wrote:
>
> On Mon, 2020-08-03 at 11:29 +0200, Miklos Szeredi wrote:
> > On Thu, Jul 23, 2020 at 12:48 PM David Howells
> > wrote:
> >
> > > > > __u32 topology_changes;
> > > > > __u32 attr_changes;
> > > > >
On Mon, 2020-08-03 at 11:29 +0200, Miklos Szeredi wrote:
> On Thu, Jul 23, 2020 at 12:48 PM David Howells
> wrote:
>
> > > > __u32 topology_changes;
> > > > __u32 attr_changes;
> > > > __u32 aux_topology_changes;
> > >
> > > Being 32bit this
On Mon, 2020-08-03 at 13:31 +0100, David Howells wrote:
> Ian Kent wrote:
>
> > > I'm changing it so that the fields are 64-bit, but initialised
> > > with the
> > > existing mount ID in the notifications set. The fsinfo set
> > > changes that
> > > to a unique ID. I'm tempted to make the uniqu
Ian Kent wrote:
> > I'm changing it so that the fields are 64-bit, but initialised with the
> > existing mount ID in the notifications set. The fsinfo set changes that
> > to a unique ID. I'm tempted to make the unique IDs start at UINT_MAX+1 to
> > disambiguate them.
>
> Mmm ... so what would
On Mon, 2020-08-03 at 12:49 +0100, David Howells wrote:
> Miklos Szeredi wrote:
>
> > OTOH mount notification is way smaller and IMO a more mature
> > interface. So just picking the unique ID patch into this set might
> > make sense.
>
> But userspace can't retrieve the unique ID without fsinfo
Miklos Szeredi wrote:
> OTOH mount notification is way smaller and IMO a more mature
> interface. So just picking the unique ID patch into this set might
> make sense.
But userspace can't retrieve the unique ID without fsinfo() as things stand.
I'm changing it so that the fields are 64-bit, bu
On Mon, Aug 3, 2020 at 12:18 PM David Howells wrote:
>
> Miklos Szeredi wrote:
>
> > > fsinfo() then allows you to retrieve them by path or by mount ID.
> >
> > Shouldn't the notification interface provide the unique ID?
>
> Hmmm... If I'm going to do that, I have to put the fsinfo-core branch f
Miklos Szeredi wrote:
> > fsinfo() then allows you to retrieve them by path or by mount ID.
>
> Shouldn't the notification interface provide the unique ID?
Hmmm... If I'm going to do that, I have to put the fsinfo-core branch first
otherwise you can't actually retrieve the unique ID - and thus
Miklos Szeredi wrote:
> > fsinfo() then allows you to retrieve them by path or by mount ID.
>
> Shouldn't the notification interface provide the unique ID?
It could make sense - instead of the reusable mnt_id.
David
On Fri, Jul 24, 2020 at 1:36 PM David Howells wrote:
>
> Ian Kent wrote:
>
> > I was wondering about id re-use.
> >
> > Assuming that ids that are returned to the idr db are re-used
> > what would the chance that a recently used id would end up
> > being used?
> >
> > Would that chance increase a
On Thu, Jul 23, 2020 at 12:48 PM David Howells wrote:
>
> > > __u32 topology_changes;
> > > __u32 attr_changes;
> > > __u32 aux_topology_changes;
> >
> > Being 32bit this introduces wraparound effects. Is that really worth it?
>
> You'd have
Ian Kent wrote:
> I was wondering about id re-use.
>
> Assuming that ids that are returned to the idr db are re-used
> what would the chance that a recently used id would end up
> being used?
>
> Would that chance increase as ids are consumed and freed over
> time?
I've added something to deal
On Fri, 2020-07-24 at 11:19 +0100, David Howells wrote:
> David Howells wrote:
>
> > > What guarantees that mount_id is going to remain a 32bit entity?
> >
> > You think it likely we'd have >4 billion concurrent mounts on a
> > system? That
> > would require >1.2TiB of RAM just for the struct m
David Howells wrote:
> > What guarantees that mount_id is going to remain a 32bit entity?
>
> You think it likely we'd have >4 billion concurrent mounts on a system? That
> would require >1.2TiB of RAM just for the struct mount allocations.
>
> But I can expand it to __u64.
That said, sys_nam
Miklos Szeredi wrote:
> On Wed, Mar 18, 2020 at 4:05 PM David Howells wrote:
> >
> > Add a mount notification facility whereby notifications about changes in
> > mount topology and configuration can be received. Note that this only
> > covers vfsmount topology changes and not superblock events.
On Sun, Jun 14, 2020 at 5:07 AM Ian Kent wrote:
>
> On Thu, 2020-04-02 at 17:19 +0200, Miklos Szeredi wrote:
> >
> > > Firstly, a watch queue needs to be created:
> > >
> > > pipe2(fds, O_NOTIFICATION_PIPE);
> > > ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
> > >
> > > then a not
On Thu, 2020-04-02 at 17:19 +0200, Miklos Szeredi wrote:
>
> > Firstly, a watch queue needs to be created:
> >
> > pipe2(fds, O_NOTIFICATION_PIPE);
> > ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
> >
> > then a notification can be set up to report notifications via that
> > que
21 matches
Mail list logo
