Názory k článku
ExtFUSE rychlejší FUSE používající eBPF

zároveň se tím vyřeší nefungující cache u FUSE přes atime, pěkné :).

Dnešní doba je tak hype, že někteří zapomněli, že FS API je neskutečně univerzální. Pokud databázi zpřístupním přes FUSE, mohu výsledek přes smb dostat do Windows a tam k procházení dat může posloužit libovolný průzkumník nebo editor, dokonce je možné vyhledávat.

Máme takhle udělanou wiki, kromě toho, že je na webu, je možné s ní pracovat přes FS API. Stejně tak se to dá dobře použít pro různé číselníky nebo reporty, velice snadno a levně se poté integrují dále.

S timto pristupem jsem narazil u nekterych softu ktere se snazi prednacitat obsah slozek (napr. Adobe Premiere). Neskutecne to spomaluje praci, kdyz mate hodne slozek - nechapu proc se kazda otevira a nepocka to na me, jakozto toho kdo vi co chce.

To zni dost zajimave. Bylo by mozne dat nejakou konkretnejsi ukazku? Je to neco jako mysqlfuse? mongofuse ? Vidim zajimave projekty v alfa verzich... takova vec by castecne vyoutovala veci jako mysql-workbench, compas atd...

rád bych, ale bohužel vše je closed source :(.

Základem je autofs a třeba v Javě se dobře používá https://github.com/SerCeMan/jnr-fuse a není to nepodobné tomuhle https://github.com/Alluxio/alluxio/tree/master/integration/fuse, teď experimentálně zkoušíme rust, ale není s tím dostatek zkušeností, ty možná se někdy v budoucnu uvolní jako open source, usiluji o to, Java věci těžko, je tady morální odpor.

Nemá smysl tolik uvažovat o tom nahradit celý workbench, primárně je to velice užitečné pro zpřístupnění statických dat, reportů a martů k integraci k legacy systémům a hlavně Windows stanicím, kde pak přes kerberos a cross realm funguje bezproblémově ACL a single sign on přes Windows login, tj. uživatelé nic neřeší, data mají na svých stanicích jako by nic, interně v audit logu poté vidím konkrétní sql a konkrétní přístupy na data, bezpečnost s tím není nikterak narušena.

Lze si s tím poměrně hezky pohrát a vymyslet spousty různých služeb, věčné problém jak dostat do BI nástrojů data tím najednou odpadají, načíst csv, json umí všechny nástroje. Není ani takový problém s latencí, vlastní DC, interní síť, vše do jednotek ms.

Dotaz - nema nahodou ten Berkley packet filter neco spolecneho s nejakym agresivnim/efek­tivnim systemem vytezovani linky ? Asi jsem o tom cetl v nejake bakalarce, uz nevim kde. Vynikajici system, ale kazdy jeho konkurent nasazeny vedle nej v zatezi ostrouha.

Nikoli, to je něco úplně jiného. Berkeley packet filter jen jen firewall na linuxu (vlastně náhrada za iptables). To, o čem píšete, je jiný algoritmus řízení okna potvrzování TCP/IP paketů: Řízení toku algoritmem BBR: buldozer nebere ohledy na ostatní spojení.

Berkeley packet filter jen jen firewall na linuxu (vlastně náhrada za iptables).

Obávám se, že si pletete (e)BPF a bpfilter.

(e)BPF je implementace filtrování v jádru (pomocí VM), tedy funkcí přibližně odpovídá Netfilteru, a bpfilter je ovládací program v user space, takže odpovídá iptables, ne? Jasně, ten firewall v kernelu se jmenuje Netfilter, iptables je jen ovládací program, ale spousta lidí tomu říká iptables jako celku.

BPF není žádný firewall, BPF je jazyk. Nebo se na něj můžete dívat jako na instrukční sadu pro virtuální stroj, který má jednu z implementací i v linuxovém jádře.

Původní varianta, velmi jednoduchá a velmi omezená, se primárně opravdu používala k filtraci paketů, ale ne ve smyslu firewallu, ale k filtraci paketů přijímaných určitým socketem. V praxi to využíval především sniffing pomocí libpcap, kde se využívala možnost inteligentně filtrovat sledované pakety už v jádře, aby se libpcap (a potažmo tcpdumpu, wiresharku apod.) předávaly jen ty pakety, které ho zajímají (proto tam takyé je možnost oříznutí paketu na zvolenou délku, která jinde moc smyslu nemá).

Rozšířená varianta označovaná eBPF už je mnohem chytřejší a složitější, takže se používá i jinde, např. v článku zmíněné aplikace jako seccomp nebo tracing (a nebo koneckonců třeba extFUSE, o kterém je zprávička). Jednou z těch aplikací je i XDP umožňující zpracování paketů na nejnižší úrovni, ještě před tím, než vstoupí do síťového stacku (než se vytvoří skb), ideální by bylo mít implementaci ještě v hardware síťové karty, ale na tom se AFAIK teprve pracuje. XDP lze sice využít i k filtraci paketů (a je to i jednou z hlavních motivací), ale za náhradu netfilteru/iptables ho při nejlepší vůli označit nelze.

Tou se snaží být až bpfilter, hodně nový projekt (přelom 2017/18), který implementuje filtraci na podobných místech jako netfilter, ale pomocí eBPF programů místo pravidel (xtables) nebo speciálního bytecode (nftables). Jedním z cílů je i vytvoření vrstvy, která by tradiční rozhraní iptables (přičemž je otázka na jaké úrovni) a/nebo nftables překládala na eBPF programy pro bpfilter, takže by userspace v ideálním případě "nic nepoznal".

V každém případě je věta "Berkeley packet filter jen jen firewall na linuxu (vlastně náhrada za iptables)." chybná v příliš mnoha ohledech. BPF není firewall, už vůbec ne náhrada za iptables a zavádějící je ostatně i to na linuxu. Hint: pozorně si prohlédněte tento článek odkazovaný z LWN článku o eBPF; Konkrétně doporučuji pozornosti první řádek nadpisu ("The BSD Packet Filter"), datum (19.12.1992) a skutečnost, že řetězec "linux" se v celém článku vůbec nevyskytuje.