Re: inotify limits - thousands (tens of thousands?) of watches

[Martin Steigerwald <ms@teamix.de>]

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

Am Mittwoch, 20. Mai 2009 schrieb Marcin Krol:
> Martin Steigerwald wrote:
> > Hmmm, I think you could just run a rsync periodically. It might even be
> > faster detecting changed files.
>
> I beg to differ on this: rsync does quite intensive (in terms of disk
> activity and CPU activity) comparisons at the beginning of
> synchronization. It's pretty light later, true, but running rsync every
> few minutes on entire /home is IMO out of question.

Another idea that might be applicable: 

We have a clustered setup - exactly also where that inotify ruby script runs - 
that used LVM and SoftRAID 1 for providing mirroring between both locations.

In each locations there is a RAID array with some hardware RAID, i.e. 
redundant in itself. Each RAID array is connected via FC to both cluster 
servers. Then we layer a SoftRAID 1 on top of it. Both cluster servers see 
the SoftRAID 1 device. One usually only does NFS and one usually only MySQL. 
Thus we made two volume groups. One of them is used by the NFS server only 
and the other one by the MySQL server.

In failover case the remaining server stoniths the failed server and takes 
over the volume group of it.

This way one of the servers could fail and the remaining server will be able 
to access the most recent data. And one of the externel RAID arrays could 
fail as well.

This worked remarkably well for more than a year, too. It won't work when you 
need to access the same volumes on both servers simultaneously, obviously.

-- 
Martin Steigerwald - team(ix) GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]