Re: [malware-list] A few concerns about fanotify implementation.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2011-06-06 at 13:19 +0400, Vasily Novikov wrote:
> >> 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.

Well, you are both correct.  If you add a mark with only 'ignored'
events set it will not pin the inode into the kernel.  If the system
starts to get under memory pressure the kernel will kick unused inodes
and any associated ignored marks out of ram.  Inodes with 'real' events
attached will be pinned in memory and cannot be evicted under memory
pressure.

-Eric

--
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


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux