Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Mar 2015 23:48:31 +0100
From:      Mateusz Guzik <mjguzik@gmail.com>
To:        Oliver Pinter <oliver.pinter@hardenedbsd.org>
Cc:        int0dster@gmail.com, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Shawn Webb <shawn.webb@hardenedbsd.org>
Subject:   Re: file system change notifications
Message-ID:  <20150311224831.GB18699@dft-labs.eu>
In-Reply-To: <CAPQ4ffvOUDemE4YMPQ89mQAZ_ojUy9Ou8OFkaihS-NEFz42YfQ@mail.gmail.com>
References:  <C4BD68D4-0570-4731-AFA2-CDD4DD5490E5@westryn.net> <CAF10W3yCgeZfz9B4hEepTM1A5wdL60L9fhBGWONrMJ_75jMiww@mail.gmail.com> <F2A12ACA-3D13-4789-94CA-BCBDE4A0A87B@westryn.net> <CAPQ4ffvOUDemE4YMPQ89mQAZ_ojUy9Ou8OFkaihS-NEFz42YfQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 11, 2015 at 11:11:14PM +0100, Oliver Pinter wrote:
> Take a look at dazuko kernel module. Probably you should forward port
> them, because they are obsoleted.
> 

I checked the module out of curiosity. Their approach was to wrap various
syscalls and work from there. This is used to be the common approach
several years back it has a lot of shortcomings, complete lack of
reliability being the biggest one.

As for better implementation: current namecache does not guarantee name
resolution (even if name was entered) and not all names end up in the
cache in the first place.

Lack of reliability comes from the fact that the cache does not pin
vnodes in any way.

The cache is also protected with one sx lock and requires users to get
and drop refs during lookups.

As such, I would say that the best course of action is implementing new
cache instead of hacking current implementatin.

Then something could be made on top of that.

> On Wed, Mar 11, 2015 at 10:54 PM, Kim Shrier <kim@westryn.net> wrote:
> > On Mar 11, 2015, at 1:14 PM, Ivan Krivonos <int0dster@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> Have not read this paper, but why just don`t kqueue() ?
> >>
> >
> > Apparently, you have to have a file descriptor for every file you want to
> > monitor, if I read things right.  This is prohibitive with 100,000+ files.
> > It also means that you cannot unmount a file system if you are monitoring
> > any files in it, since the file system is considered busy.
> >
> > Kim
> > _______________________________________________
> > freebsd-hackers@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

-- 
Mateusz Guzik <mjguzik gmail.com>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150311224831.GB18699>