DNOTIFY to INOTIFY migration

DNOTIFY to INOTIFY migration

[David Heidelberger]

Hello,

in linux kernel is DNOTIFY actually marked as deprecated, with superior 
replacement INOTIFY.

Is any plan to migrate rpc.idmapd to INOTIFY? As I looked, it's just one 
file.

If there is some on-going porting, I'd like to test/report bugs/send 
patches, otherwise I'd like to try port it.

Thank you for answer
David Heidelberger (okias)

Re: DNOTIFY to INOTIFY migration

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

On Fri, 07 Mar 2014 21:30:34 +0100 David Heidelberger
<david.heidelberger@ixit.cz> wrote:

> Hello,
> 
> in linux kernel is DNOTIFY actually marked as deprecated, with superior 
> replacement INOTIFY.

Where is it marked as deprecated?  I would be very surprised if dnotify
wasn't supported indefinitely.

(I have no opinion on whether rpc.idmapd should be changed to use inotify,
except based on the "if it ain't broke, don't fix it" principle).

NeilBrown

> 
> Is any plan to migrate rpc.idmapd to INOTIFY? As I looked, it's just one 
> file.
> 
> If there is some on-going porting, I'd like to test/report bugs/send 
> patches, otherwise I'd like to try port it.
> 
> Thank you for answer
> David Heidelberger (okias)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: DNOTIFY to INOTIFY migration

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]

On Mon, 10 Mar 2014 01:55:15 +0100 David Heidelberger
<david.heidelberger@ixit.cz> wrote:

> Dne 2014-03-10 00:21, NeilBrown napsal:
> > On Fri, 07 Mar 2014 21:30:34 +0100 David Heidelberger
> > <david.heidelberger@ixit.cz> wrote:
> > 
> >> Hello,
> >> 
> >> in linux kernel is DNOTIFY actually marked as deprecated, with 
> >> superior
> >> replacement INOTIFY.
> > 
> > Where is it marked as deprecated?  I would be very surprised if dnotify
> > wasn't supported indefinitely.
> 
> 
> Dnotify is a directory-based per-fd file change notification system
> 	  that uses signals to communicate events to user-space.  There exist
> 	  superior alternatives, but some applications may still rely on
> 	  dnotify.
> 
> (fs/notify/dnotify/Kconfig)

The fact that the new alternatives are (supposedly) superior doesn't mean the
old are deprecated.


> 
> In this moment, for modern systems I'm no aware of software actually 
> using DNOTIFY.

I tend to use DNOTIFY because, much as I hate signals, it actually works with
python while python doesn't know about the new inotify systemcall (though I
know there is now some plug-in thing).
I suspect there is a lot of software that uses DNOTIFY that you don't know
about.


> 
> Actually there is choice between INOTIFY and FSNOTIFY.
> > 
> > (I have no opinion on whether rpc.idmapd should be changed to use 
> > inotify,
> > except based on the "if it ain't broke, don't fix it" principle).
> 
> Well, I'd like to propose build option which notify system include. It 
> seems like *notify support reside only in rpc.idmapd, so it shouldn't be 
> hard.

Feel free to post a patch.  You should make it clear how the change actually
benefits nfs-utils.  Make sure you don't use the word "deprecated" because
dnotify is *not* deprecated.

Thanks,
NeilBrown


> 
> David
> > 
> > NeilBrown
> > 
> >> 
> >> Is any plan to migrate rpc.idmapd to INOTIFY? As I looked, it's just 
> >> one
> >> file.
> >> 
> >> If there is some on-going porting, I'd like to test/report bugs/send
> >> patches, otherwise I'd like to try port it.
> >> 
> >> Thank you for answer
> >> David Heidelberger (okias)
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-nfs" 
> >> in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: DNOTIFY to INOTIFY migration

[Al Viro]

On Mon, Mar 10, 2014 at 10:21:02AM +1100, NeilBrown wrote:
> On Fri, 07 Mar 2014 21:30:34 +0100 David Heidelberger
> <david.heidelberger@ixit.cz> wrote:
> 
> > Hello,
> > 
> > in linux kernel is DNOTIFY actually marked as deprecated, with superior 
> > replacement INOTIFY.
> 
> Where is it marked as deprecated?  I would be very surprised if dnotify
> wasn't supported indefinitely.

Unfortunately, it will be - once it's in, it's in.

> (I have no opinion on whether rpc.idmapd should be changed to use inotify,
> except based on the "if it ain't broke, don't fix it" principle).

I still don't understand WTF does rpc.imapd *want* either of those, TBH.

Said that, the original posting does read a bit like "herpes is so last century,
shouldn't we upgrade to clap by now?"...*0O(and I don't want to think what
that makes fanotify, thank you very much)

Re: DNOTIFY to INOTIFY migration

[David Heidelberger]

Dne 2014-03-10 00:21, NeilBrown napsal:
> On Fri, 07 Mar 2014 21:30:34 +0100 David Heidelberger
> <david.heidelberger@ixit.cz> wrote:
> 
>> Hello,
>> 
>> in linux kernel is DNOTIFY actually marked as deprecated, with 
>> superior
>> replacement INOTIFY.
> 
> Where is it marked as deprecated?  I would be very surprised if dnotify
> wasn't supported indefinitely.


Dnotify is a directory-based per-fd file change notification system
	  that uses signals to communicate events to user-space.  There exist
	  superior alternatives, but some applications may still rely on
	  dnotify.

(fs/notify/dnotify/Kconfig)

In this moment, for modern systems I'm no aware of software actually 
using DNOTIFY.

Actually there is choice between INOTIFY and FSNOTIFY.
> 
> (I have no opinion on whether rpc.idmapd should be changed to use 
> inotify,
> except based on the "if it ain't broke, don't fix it" principle).

Well, I'd like to propose build option which notify system include. It 
seems like *notify support reside only in rpc.idmapd, so it shouldn't be 
hard.

David
> 
> NeilBrown
> 
>> 
>> Is any plan to migrate rpc.idmapd to INOTIFY? As I looked, it's just 
>> one
>> file.
>> 
>> If there is some on-going porting, I'd like to test/report bugs/send
>> patches, otherwise I'd like to try port it.
>> 
>> Thank you for answer
>> David Heidelberger (okias)
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" 
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DNOTIFY to INOTIFY migration

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

On Mon, 10 Mar 2014 00:20:15 +0000 Al Viro <viro@ZenIV.linux.org.uk> wrote:

> On Mon, Mar 10, 2014 at 10:21:02AM +1100, NeilBrown wrote:
> > On Fri, 07 Mar 2014 21:30:34 +0100 David Heidelberger
> > <david.heidelberger@ixit.cz> wrote:
> > 
> > > Hello,
> > > 
> > > in linux kernel is DNOTIFY actually marked as deprecated, with superior 
> > > replacement INOTIFY.
> > 
> > Where is it marked as deprecated?  I would be very surprised if dnotify
> > wasn't supported indefinitely.
> 
> Unfortunately, it will be - once it's in, it's in.
> 
> > (I have no opinion on whether rpc.idmapd should be changed to use inotify,
> > except based on the "if it ain't broke, don't fix it" principle).
> 
> I still don't understand WTF does rpc.imapd *want* either of those, TBH.

The rpc_pipefs filesysem which is mounted on /var/lib/nfs/rpc_pipefs creates
new channels for talking to userspace by making new pipes appear in some
directory.  Any client needs to arrange some notification for these new pipes
appearing so that it can open them and hold a conversation over them.
This calls for dnotify (in gssd and idmapd) or inotify (in blkmapd).

NeilBrown

> 
> Said that, the original posting does read a bit like "herpes is so last century,
> shouldn't we upgrade to clap by now?"...*0O(and I don't want to think what
> that makes fanotify, thank you very much)


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: DNOTIFY to INOTIFY migration

[Al Viro]

On Mon, Mar 10, 2014 at 11:56:59AM +1100, NeilBrown wrote:

> > I still don't understand WTF does rpc.imapd *want* either of those, TBH.
> 
> The rpc_pipefs filesysem which is mounted on /var/lib/nfs/rpc_pipefs creates
> new channels for talking to userspace by making new pipes appear in some
> directory.  Any client needs to arrange some notification for these new pipes
> appearing so that it can open them and hold a conversation over them.
> This calls for dnotify (in gssd and idmapd) or inotify (in blkmapd).

... or just adding ->poll() to the directory in question and using the
normal syscalls instead of all that weird crap.

Re: DNOTIFY to INOTIFY migration

[David Heidelberger]

Neil, what you think? Should I try someway simplify this as Al proposed?

Dne 2014-03-10 02:45, Al Viro napsal:
> On Mon, Mar 10, 2014 at 11:56:59AM +1100, NeilBrown wrote:
> 
>> > I still don't understand WTF does rpc.imapd *want* either of those, TBH.
>> 
>> The rpc_pipefs filesysem which is mounted on /var/lib/nfs/rpc_pipefs 
>> creates
>> new channels for talking to userspace by making new pipes appear in 
>> some
>> directory.  Any client needs to arrange some notification for these 
>> new pipes
>> appearing so that it can open them and hold a conversation over them.
>> This calls for dnotify (in gssd and idmapd) or inotify (in blkmapd).
> 
> ... or just adding ->poll() to the directory in question and using the
> normal syscalls instead of all that weird crap.

Re: DNOTIFY to INOTIFY migration

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]

On Wed, 12 Mar 2014 23:52:31 +0100 David Heidelberger
<david.heidelberger@ixit.cz> wrote:

> Neil, what you think? Should I try someway simplify this as Al proposed?

No, Al is just letting off steam.

He hates the *notify interfaces (not without reason) and wishes people would
avoid them where-ever possible.

However rpc_pipefs does implement these interfaces, and doesn't implement
'poll' on directories, so changing nfs-utils to use poll wouldn't help.

I really don't think there is any need to do anything.  It works and there is
not expectation that it will every stop working, and no evidence that there
is any problem with how it works.  So best to leave it alone.

NeilBrown


> 
> Dne 2014-03-10 02:45, Al Viro napsal:
> > On Mon, Mar 10, 2014 at 11:56:59AM +1100, NeilBrown wrote:
> > 
> >> > I still don't understand WTF does rpc.imapd *want* either of those, TBH.
> >> 
> >> The rpc_pipefs filesysem which is mounted on /var/lib/nfs/rpc_pipefs 
> >> creates
> >> new channels for talking to userspace by making new pipes appear in 
> >> some
> >> directory.  Any client needs to arrange some notification for these 
> >> new pipes
> >> appearing so that it can open them and hold a conversation over them.
> >> This calls for dnotify (in gssd and idmapd) or inotify (in blkmapd).
> > 
> > ... or just adding ->poll() to the directory in question and using the
> > normal syscalls instead of all that weird crap.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]