GNU/Linux >> Znalost Linux >  >> Linux

Myšlenky na sledování změn souborů s Linuxem přes síť

Sledování změn v adresáři pomocí Linuxu je možné pomocí dobře známého mechanismu inotify. S inotify je možné nastavit sledování na adresář, nakonfigurovat jej tak, aby sledoval události v obsahu, a když se něco stane, budete dostávat zprávy na deskriptoru souboru. To funguje perfektně, když je adresář na místním úložišti, jako je pevný disk, SSD nebo USB disk, ale nestačí, když je adresář na síťovém souborovém systému, když je úložiště na jiném počítači. Jiný uživatel pracující ve stejném adresáři, připojený přes stejný nebo jiný souborový systém, může odstranit soubor a hodinky, které jste na něm nastavili, nedostanou upozornění.

Proč tomu tak je?

Podle návrhu získá inotify výsledek operace (jako mkdir nebo chmod), ale není známo, na jakém souborovém systému hodinky jsou (černá skříňka), aby bylo možné inotify. Souborový systém "neví", že bylo nastaveno sledování, a proto nemůže provést správnou akci, jako je upozornění vzdáleného hostitele, že někdo chce sledovat adresář.

Dokud jste jediným uživatelem, není problém. Problém se stává, když v adresáři, který chcete sledovat, pracuje více uživatelů.

Toto chování můžete porovnat s veřejnou knihovnou. Když jste jediným uživatelem, můžete vědět, které knihy jsou dostupné a které ne, protože víte, které z nich jste si půjčili. To již není možné, když nejste jediným uživatelem, knihy si půjčuje více uživatelů.

V takovém případě by měl někdo v knihovně spravovat to, co si kterýkoli uživatel vypůjčil (což je běžný případ), a vy musíte tohoto člověka kontaktovat, abyste věděli, zda je kniha dostupná nebo ne. Je to jako požádat někoho, aby vás informoval, až bude kniha, která momentálně není k dispozici, znovu dostupná.

Toto spojení s knihovnou, abychom vás informovali, nefunguje s Linuxem, kde je samozřejmě knihovna vzdálené úložiště a server je „někdo“, kdo pracuje v knihovně.

Aby to fungovalo s Linuxem, znamená to, že vzdálený server dostane upozornění, že bylo nastaveno sledování.

Souborové systémy jako CIFS a nejnovější verze NFS ve skutečnosti obsahují podporu odesílání hodinek na server:pro CIFS na řádku 6438 fs/cifs/cifssmb.c jádra 4.1.2 je zpráva SMB pro toto (NT_TRANSACT_NOTIFY_CHANGE) zakomentována ale stále přítomný. Důvod, proč to komentovat, je ten, že to fungovalo s dnotify, což už dávno není výchozí systém fsnotify pro Linux.


Zprovoznění přesměrování hodinek na Linuxu se síťovými souborovými systémy a FUSE je možné prostřednictvím prostoru jádra.

Nedávno jsem se pokusil implementovat toto "přeposílání hodinek na server" pomocí FUSE. Musel jsem opravit:

Subsystém jádra fsnotify, který informuje modul jádra FUSE o nastavení nebo odstranění sledování na inode.

Modul jádra FUSE podnikne akci poté, co informuje fsnotify. Zavedl jsem nový operační kód
FUSE_FSNOTIFY, který modul jádra posílá démonovi uživatelského prostoru spolu s číslem inode a maskou.

Knihovna FUSE pro příjem a zpracování volání FUSE_FSNOTIFY voláním správné funkce souborového systému uživatelského prostoru.

Knihovna FUSE pro příjem a zpracování událostí fs a jejich hlášení zpět do VFS.

Když se podíváme blíže na to, jak věci fungují, když byly hodinky úspěšně nastaveny souborovým systémem uživatelského prostoru na jejich backendu (všimněte si, že je také možné, aby odpověděly ENOSYS), může backend kdykoli odeslat událost na hodinky, dokud hodinky jsou odstraněny. Co dělat s touto událostí?

Možný scénář:

Zaveďte zvláštní operační kód FUSE FUSE_FSNOTIFY_EVENT, přeložte masku v události přijaté z backendového protokolu něčím, čemu fsnotify rozumí, a odešlete ji zpět do modulu FUSE pomocí nového operačního kódu, inodu hodinek, názvu položky a přeloženou masku. Modul FUSE jej na svém tahu odešle do subsystému fsnotify, který informuje posluchače (inotify nebo fanotify), kde je poskytnuta informace, že událost je na backendu. (je vyžadován zvláštní příznak události, například pro inotify masky události IN_REMOTE, pro fanotify FAN_REMOTE). Je na posluchači, co s touto informací udělá. Místní VFS může, ale nemusí být již aktuální.

Poznámky:

Převedení masky z backendu na něco, čemu fsnotify rozumí, může být velmi snadné a ne tak snadné, v závislosti na události. Základní události jako vytvoření (nebo odstranění) záznamu ve sledovaném adresáři je jednoduché (FS_CREATE, resp. FS_DELETE), změna vlastníka také není tak náročná (FS_ATTRIB), ale něco jako rozšířený atribut (SMB používá těch hodně) lze přeložit pouze do něčeho obecného jako FS_ATTRIB.

Modul FUSE by měl zkontrolovat, zda jsou hodinky a/nebo inode stále platné a zda maska ​​hodinek platí pro masku události.

Jsou vyžadovány extra bity masky IN_REMOTE (pro inotify) a FAN_REMOTE (pro fanotify).

Je třeba se vyvarovat dvojích informací. To je ošemetné. Například vytvoření souboru ve sledovaném adresáři na stejném hostiteli, na kterém je zapnuto sledování. Když je tato operace úspěšná, způsobí to událost fsnotify FS_CREATE a také vytvoří FS_CREATE | Událost FS_REMOTE, protože operace byla úspěšně provedena na backendu, což má za následek tuto zprávu (z backend → pojistková knihovna → modul jádra FUSE → subsystém fsnotify → inotify a/nebo fanotify).

Jedním ze způsobů, jak to vyřešit, je požádat backend, aby zasílal pouze události iniciované ostatními. Pro backend je docela jednoduché porovnat iniciátora (hostitele) události FS s hostitelem, který provádí připojení.

Dalším řešením je porovnat hlášenou událost s místní mezipamětí v knihovně fuse a modulu FUSE. V příkladu vytvoření souboru by knihovna (a modul FUSE) měla zkontrolovat, zda záznam již existuje ve sledovaném adresáři. Pokud ne, není to iniciováno tímto hostitelem. U smazání je to podobné.

Pro jiné události, jako je zápis do souboru nebo změna vlastníka, tato metoda nestačí, další informace o tom, co se změnilo na vzdáleném místě (např. nová velikost, nový vlastník), musí být ve zprávě zaslané vzdáleným hostitelem.

Pokud backend tyto informace neposkytuje, dalším řešením je přimět démona zodpovědného za sledování událostí FS jménem klientů udržovat mezipaměť nedávných místních událostí. Pokud je hlášena vzdálená událost a v mezipaměti není nalezen místní ekvivalent, je iniciována jiným hostitelem. To může být složité, protože události jsou hlášeny pomocí připojení pro určitého uživatele, ostatní uživatelé mohou nebo nemusí mít oprávnění přijímat události. A jak velká bude tato keš?

Použil jsem FUSE výše, myslím, že je to podobné pro jiné souborové systémy jako CIFS a NFS.

Jo a ano, je tu ještě další možnost:prostě každých 5 sekund hlasovat.

Stef Bon


Linux
  1. Sledujte příkazy a úkoly pomocí příkazu watch v systému Linux

  2. Najděte soubory a adresáře v Linuxu pomocí příkazu find

  3. Zákulisí s linuxovými kontejnery

  1. Zkontrolujte stav souboru v systému Linux pomocí příkazu stat

  2. Vynucení změn systémového hesla systému Linux pomocí příkazu chage

  3. sledování změn souborů c++ linux

  1. Začínáme s příkazem tac systému Linux

  2. Monitorování úrovně mikrofonu pomocí nástroje příkazového řádku v Linuxu

  3. Jaký je koncept vytvoření souboru s nula bajty v Linuxu?