1. The file is thrown out of the cache only when it is modified. But in
case there are different scan options for different dirs that's not
enough. So we also need it to be evicted from cache on rename or number
of hard links change.
This is interesting, as it makes the cache less efficient for those
users who don't have different scanning within a filesystem.
Our only equivalent things are exclusions, which we handle by not
marking the responses for exclusions as cache-able.
I suppose rename or make hard link is less frequent operation then
modify so I believe it won't add a significant overhead.
2. We can't use unlimited cache because it can potentially grab too much
memory and slow down a system. In case we use limited cache it can be
easily filled with not very frequently used files. So the only option we
have at the moment is to clear cache every time it is full.
The solution we consider the most appropriate is to introduce
replaceable marks and LRU cache for them in fanotify.
So we suggest to introduce a new flag FAN_MARK_REPLACEABLE for marks.
IIRC the cache is stored in the inodes themselves, so will automatically
be culled as inodes are pushed out of memory?
If I understood the code correctly there is no cache by itself. It's
just implemented through marks and it's ignored_mask field. So there is
a list of marks for each inode that is empty initially. But when you add
mark to this list you allocate fsnotify_mark structure which is about 64
bytes.
--
Best regards,
Vasily Novikov | Software developer | Kaspersky Lab
Direct: +7 495 123 45 67 x2344 | Mobile: +7 964 786 44 82 |
vasily.novikov@xxxxxxxxxxxxx
10/1, 1st Volokolamsky Proezd, Moscow, 123060, Russia |
www.kaspersky.com, www.securelist.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
