Ik heb onlangs een dropbox-systeem gemaakt met inotify, waarbij ik let op bestanden die in een bepaalde map zijn gemaakt. De map die ik bekijk is gemount vanaf een NFS-server en inotify gedraagt zich anders dan ik zou verwachten. Overweeg het volgende scenario waarin een inotify-script wordt uitgevoerd op machine A, kijkend naar /some/nfs/dir/also/visible/to/B.
-Als u machine A gebruikt om een bestand aan te maken in /some/nfs/dir/also/visible/to/B, gedraagt het script zich zoals verwacht. Als machine B dezelfde actie uitvoert, wordt het script niet op de hoogte gesteld van een nieuw bestand dat in de map is geplaatst.
-Als het script op de NFS-server wordt uitgevoerd, wordt het gewaarschuwd wanneer er bestanden worden gemaakt op zowel computer A als computer B.
Is dit een bug in de bug in het pakket dat ik gebruik om toegang te krijgen tot inotofy, of is dit te verwachten gedrag?
Antwoord 1, autoriteit 100%
inotify vereist ondersteuning van de kernel om te werken. Wanneer een applicatie een directory volgt, vraagt het de kernel om het te informeren wanneer die veranderingen plaatsvinden. Wanneer de wijziging plaatsvindt, geeft de kernel niet alleen de wijzigingen op schijf weg, maar ook het observatieproces.
Op een externe NFS-machine is de wijziging niet zichtbaar voor de kernel; het gebeurt volledig op afstand. NFS dateert van vóór inotify en er is geen ondersteuning op netwerkniveau voor in NFS, of iets vergelijkbaars.
Als je dit wilt omzeilen, kun je een service uitvoeren op de opslagserver (aangezien die kernel altijd wijzigingen in het bestandssysteem zal zien) die brokers inotify-verzoeken voor externe machines, en de gegevens doorsturen naar de externe clients.
Bewerken:het lijkt me vreemd dat NFSzou moeten zijn beschuldigd van het gebrek aan steun voor inotify.
Network File System (NFS) is een gedistribueerd bestandssysteemprotocol dat oorspronkelijk is ontwikkeld door Sun Microsystems in 1984, wikipedia-artikel
Echter:
Inotify (inode-notificatie) is een Linux-kernelsubsysteemdat fungeert om bestandssystemen uit te breiden om wijzigingen in het bestandssysteem op te merken. […] Het is opgenomen in de hoofdlijn Linux-kernel vanaf release 2.6.13 (18 juni 2005) […]. wikipedia-artikel
Het is moeilijk te verwachten dat een draagbaar netwerkprotocol/-applicatie een specifieke kernelfunctie ondersteunt die is ontwikkeld voor een ander besturingssysteem en die meer dan twintig jaar laterverscheen. Zelfs als het erextensies voor zou bevatten, zouden ze niet beschikbaar of nuttig zijn op andere besturingssystemen.
*nadruk van mij in alle gevallen
Nog een probleem hiermee; Laten we aannemen dat we helemaal geen netwerk gebruiken, maar eerder een lokaal bestandssysteem met goede inotify-ondersteuning: ext3 (stel dat het is gemount op /mnt/foo). Maar in plaats van een echte schijf, wordt het bestandssysteem gemount vanaf een loopback-apparaat; en het onderliggende bestand is op zijn beurt toegankelijk op een andere locatie in de vfs (zeg, /var/images/foo.img).
Het is niet de bedoeling dat je gemounte ext3-bestandssystemen wijzigt, maar het is nog redelijk veilig om dit te doen als de wijziging de inhoud van het bestand is in plaats van metadata.
Dus stel dat een slimme gebruiker de afbeelding van het bestandssysteem (/var/images/foo.img) in een hex-editor wijzigt, waarbij de inhoud van een bestand wordt vervangen door andere gegevens, terwijl tegelijkertijd een inotify watch observeert hetzelfde bestand op het aangekoppelde bestandssysteem.
Er is geen redelijke manier om ervoor te zorgen dat inotify het observatieproces altijd op de hoogte houdt van dit soort wijzigingen. Hoewel er waarschijnlijk wat schommelingen zijn om ext3 op te merken en de wijziging te honoreren, zou niets van dat alles van toepassing zijn op, laten we zeggen, de xfs-stuurprogramma, die verder vrij gelijkaardig is.
Ook niet. Je speelt vals!. inotify kan u alleen informeren over wijzigingen die zijn opgetreden via de vfs op het daadwerkelijke mountpoint dat wordt bekeken. Als de wijzigingen buiten die VFS hebben plaatsgevonden, vanwege een wijziging in de onderliggende gegevens, kan inotify u niet helpen en is het niet ontworpen om dat probleem op te lossen.
Heeft u overwogen met behulp van een bericht wachtrij voor netwerk kennisgeving?
2, Autoriteit 9%
Voor iedereen die over deze kwestie is gekomen in de zoektocht naar een antwoord waarom bind montage op Docker zal niet file veranderingen van host directory (voor warm opnieuw laden van een app) op te sporen, is het omdat de voortplanting van het bestand wisselt tussen gastheer en houder niet aan de houder kernel.
Alleen wijzigingen ten opzichte van de container zelf wordt meegedeeld aan de kernel. Oplossing hiervoor is om je live reload nut turn on “polling mode” hebben in plaats van het gebruik van fsnotify.
3, autoriteit 8%
Ik vond een SGI FAM met behulp van een supervisor daemon te bewaken-bestanden te wijzigen. Het ondersteunt NFS en je kunt zien wat beschrijving op wiki
4
Ik ben het eens met uitleg SingleNegationElimination’s, en zou graag willen toevoegen dat iSCSI-targets zal werken, omdat ze de kernel te waarschuwen.
Dus dingen op “echte” bestandssystemen (ten opzichte van het systeem, dat is) zal leiden tot Inotify om alert. Net als Rsync’ing netto-catting iets in een gemonteerde partitie.
Als u meldingen ontvangen via inotify (of moet gebruiken inotify) kunt u een cron rsync -avz naar het bestandssysteem te maken. Nadelen zijn natuurlijk dat u echt systeem hdd ruimte.
5
het probleem notify-forwarderis dat zij geen inotifyevent teweegbrengt. Het maakt gebruik van utimeom de tijdstempel voor het bestand op het externe systeem, maar inotifyupdate mislukt om dit te zien.
Voor zover ik weet, de tijdstempel al wordt bijgewerkt wanneer u een NFS mount. Ik heb dit zelf geverifieerd tussen een Synology NAS NFS server en een Raspbian NFS (client).
Hier is mijn oplossing / hack op de client:
#!/bin/bash
path=$1
firstmd5=`ls -laR $path | md5sum | awk ' { print $1 }'`
while true
do
lastmd5=`ls -laR $path | md5sum | awk ' { print $1 }'`
if [ $firstmd5 != $lastmd5 ]
then
firstmd5=$lastmd5
echo files changed
fi
sleep 1
done
Toegegeven, betekent dit niet rapporteren over de specifieke bestand dat wordt veranderd, maar biedt wel een algemene kennisgeving haak dat er iets is veranderd.
Het is vervelend / kludgy maar als ik meer informatie nodig zou ik wat extra hacken te isoleren van de werkelijke gewijzigde bestanden te doen.