From Newsgroup: comp.os.linux.misc

Say you want to promptly duplicate what ever has been
writ to your disk on another disk, or remote drive or
cloud drive or whatever.

'inotify' and its kin can tell you what's changed,
but it's basically a POLLING sort of operation and
including an entire drive would be insanely slow.
It's a sort of localized rsync daemon.

Now SOMEWHERE Linux does put together a filename
and destination as it's about to write. The
big question is where, and can users SEE this ?

SoftRAID software does seem to tap into something
like this, so it's THERE, somewhere. I tried
looking at softRAID code but it's huge and only
just so well documented. No luck - I can't find
what it's looking at - kernel, driver, who knows ?


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

c186282 <c186282@nnada.net> wrote:

Say you want to promptly duplicate what ever has been writ to your
disk on another disk, or remote drive or cloud drive or whatever.

'inotify' and its kin can tell you what's changed,

Yep, that is its purpose.

but it's basically a POLLING sort of operation and

Incorrect. Inotify is an event driven system. There is no polling
(using the standard definiton of "polling" [1]) going on for inotify
events.

including an entire drive would be insanely slow.

Yes, but only because setting up the inotify notifications would take a
while to do, and likely need a fair amount of kernel ram to store them.

But once setup, there is no polling of any form going on.

It's a sort of localized rsync daemon.

Completely wrong, in so many ways.

Now SOMEWHERE Linux does put together a filename and destination as
it's about to write. The big question is where, and can users SEE
this ?

Inotify.

SoftRAID software does seem to tap into something like this, so it's
THERE, somewhere. I tried looking at softRAID code but it's huge and
only just so well documented. No luck - I can't find what it's
looking at - kernel, driver, who knows ?

Unless it installs a custom kernel module (unlikely) then it is most
likely using the inotify subsystem.

[1] https://en.wikipedia.org/wiki/Polling_(computer_science)
But as you are well known for having made up your own non-standard
definitions for CS terms, I felt the need to point to the standard
definition.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 4/7/26 23:58, Rich wrote:

c186282 <c186282@nnada.net> wrote:

Say you want to promptly duplicate what ever has been writ to your
disk on another disk, or remote drive or cloud drive or whatever.

'inotify' and its kin can tell you what's changed,

Yep, that is its purpose.

but it's basically a POLLING sort of operation and

Incorrect. Inotify is an event driven system. There is no polling
(using the standard definiton of "polling" [1]) going on for inotify
events.

including an entire drive would be insanely slow.

Yes, but only because setting up the inotify notifications would take a
while to do, and likely need a fair amount of kernel ram to store them.

But once setup, there is no polling of any form going on.

Ya SURE about that ???

I did some experiments a few years back and even
if you added "nothing happening" dirs the performance
got worse.

It's a sort of localized rsync daemon.

Completely wrong, in so many ways.

Now SOMEWHERE Linux does put together a filename and destination as
it's about to write. The big question is where, and can users SEE
this ?

Inotify.

SoftRAID software does seem to tap into something like this, so it's
THERE, somewhere. I tried looking at softRAID code but it's huge and
only just so well documented. No luck - I can't find what it's
looking at - kernel, driver, who knows ?

Unless it installs a custom kernel module (unlikely) then it is most
likely using the inotify subsystem.

Then RAID is essentially 'inotify("/","-r")' yet it's lightning
fast and doesn't use up all the kernel RAM doing it.

[1] https://en.wikipedia.org/wiki/Polling_(computer_science)
But as you are well known for having made up your own non-standard definitions for CS terms, I felt the need to point to the standard definition.

"Polling" in THIS case would mean reading all the file names/times
in a folder/subfolders and then reading them again X seconds later
to see if anything had changed. This could get very tedious if a
large folder is involved. I was looking for something a bit more
pro-active, only reporting what HAD changed without having to go
looking for it on the disk.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

Rich <rich@example.invalid> writes:

c186282 <c186282@nnada.net> wrote:

Now SOMEWHERE Linux does put together a filename and destination as
it's about to write. The big question is where, and can users SEE
this ?

Inotify.

Not really. inotify monitors individual files or directories. It is not
really suitable for the task which c186282 has in mind, which is
monitoring entire filesystems for changes.

For whole-system monitoring, you want fanotify.

* https://man7.org/linux/man-pages/man7/fanotify.7.html
* https://lwn.net/Articles/339399/
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 4/8/26 13:10, Richard Kettlewell wrote:

Rich <rich@example.invalid> writes:

c186282 <c186282@nnada.net> wrote:

Now SOMEWHERE Linux does put together a filename and destination as
it's about to write. The big question is where, and can users SEE
this ?

Inotify.

Not really. inotify monitors individual files or directories. It is not really suitable for the task which c186282 has in mind, which is
monitoring entire filesystems for changes.

For whole-system monitoring, you want fanotify.

* https://man7.org/linux/man-pages/man7/fanotify.7.html
* https://lwn.net/Articles/339399/

Ah ha ! Useful info ! I'll check that one out !
The man page says that many useful options were
added when the 5.1 kernel came out.

I did experiments with inotify() awhile back and
adding more folders, even unused ones, kept hurting
the times. As such it really does ACT like "polling"
the dirs/subdirs for changes. Easy to write a short
'C' app that'll do that, but if you want to do the
whole 16tb drive ... geez. May as well just run rsync
over and over and over all day.

DID keep one inotify()-based little app, for the
boss's main folder. He had a habit of, well, let's
say he wasn't great at cut-n-paste and it was a
huge deep dir.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

c186282 <c186282@nnada.net> wrote:

On 4/7/26 23:58, Rich wrote:

c186282 <c186282@nnada.net> wrote:

Say you want to promptly duplicate what ever has been writ to your
disk on another disk, or remote drive or cloud drive or whatever.

'inotify' and its kin can tell you what's changed,

Yep, that is its purpose.

but it's basically a POLLING sort of operation and

Incorrect. Inotify is an event driven system. There is no polling
(using the standard definiton of "polling" [1]) going on for inotify
events.

including an entire drive would be insanely slow.

Yes, but only because setting up the inotify notifications would take a
while to do, and likely need a fair amount of kernel ram to store them.

But once setup, there is no polling of any form going on.

Ya SURE about that ???

That's the claim on the tin.

I did some experiments a few years back and even if you added
"nothing happening" dirs the performance got worse.

I'd have to try an experiment to see, but even if "performance got
worse" that does not necessarily equate to "polling".

It's a sort of localized rsync daemon.

Completely wrong, in so many ways.

Now SOMEWHERE Linux does put together a filename and destination as
it's about to write. The big question is where, and can users SEE
this ?

Inotify.

SoftRAID software does seem to tap into something like this, so it's
THERE, somewhere. I tried looking at softRAID code but it's huge and
only just so well documented. No luck - I can't find what it's
looking at - kernel, driver, who knows ?

Unless it installs a custom kernel module (unlikely) then it is most
likely using the inotify subsystem.

Then RAID is essentially 'inotify("/","-r")' yet it's lightning
fast and doesn't use up all the kernel RAM doing it.

No, RAID (Linux MD RAID) is a kernel driver that internally handles the
write to plural disks plus checksumming to the checksum disks, and
operates at the block level, not 'file' level.

As to SoftRAID, I have no idea what that one is nor how it works.

[1] https://en.wikipedia.org/wiki/Polling_(computer_science)
But as you are well known for having made up your own non-standard
definitions for CS terms, I felt the need to point to the standard
definition.

"Polling" in THIS case would mean reading all the file names/times
in a folder/subfolders and then reading them again X seconds later
to see if anything had changed. This could get very tedious if a
large folder is involved. I was looking for something a bit more
pro-active, only reporting what HAD changed without having to go
looking for it on the disk.

And that is supposed to be the inotify subsystem.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

Richard Kettlewell <invalid@invalid.invalid> wrote:

Rich <rich@example.invalid> writes:

c186282 <c186282@nnada.net> wrote:

Now SOMEWHERE Linux does put together a filename and destination as
it's about to write. The big question is where, and can users SEE
this ?

Inotify.

Not really. inotify monitors individual files or directories. It is not really suitable for the task which c186282 has in mind, which is
monitoring entire filesystems for changes.

For whole-system monitoring, you want fanotify.

* https://man7.org/linux/man-pages/man7/fanotify.7.html
* https://lwn.net/Articles/339399/

Ah, good to know. So there's a separate interface for "monitor it
all".
--- Synchronet 3.21f-Linux NewsLink 1.2