to nije servis. potrazi odgovarajucu opciju za backup u tom text editoru.

Tnx.

Je li ti se to mozda dogadja kad editiras neke fajlove u /etc direktoriju?

I u /etc i svugde drugde ,ma backup opcija u text editorima je meni bila u pitanju,nikada mi ne bi palo na pamet da pogledam tja.

Bilo bi dobro da Linux ima to kao servis fajl sistema, kao VMS koji čuva nekoliko poslednjih revizija svakog fajla.

Ma da kako da ne, zamisli da editujes, reprocesiras,dvd ili veliki avi fajl pa da ti fajl sistem servis napravi backup
a ti se cudis sta to hdd radi pola sata a za 2 ili tri editovanja vise nemas praznog mesta na disku i lutas ,trazis, brises ma milina jedna @#$#@$!@!

Pa, može se ograničiti. Samo na male fajlove, ili samo na fajlove u određenim direktorijumima. To nije problem.

Da ali to onda ne bi bio fajl sistem servis nego linux servis ili servis neke distribucije
Kako ti da kazes fajl sistem servisu koji je implementiran u kernel gde j koji direktorijum ,da li ces ti praviti nove, itd.

Na svakom bogovetnom UNIX-u (pa i Linuxu) runtime konfiguracija kernela je implementirana, na linuxu kroz /proc npr.

Izvini pogresio sam, mislio sam samo na ovaj slucaj , koliko ja vidim takva opcija za sada nije standardno ukljucena u runtime konfigurisanje kernela a koliko je to tesko implementirati u sam kernel stvarno ne znam i ne zelim da nagadjam ,ko to zeli neka prepravlja i cacka kernel sors ili neka moli Linusa da to uradi. Po mom misljenju to znaci da takav servis(za sada) mora biti napravljen "aplikativno" i da ne zavisi od kernela,fajl sistema (a da ipak iskoristi njihove mogucnosti) ali ne moze se to zvati fajl sistem servis
nego to je aplikacioni servis ko i svaki drugi,prvenstveno namenjen za serverska i database okruzenja
mada nista nije iskljuceno.
Uostalom kome to treba verovatno ima aplikacija koje to rade, cak je moguce lako sa skripticama dobiti zeljeni rezultat ,verovatno je zbog toga nepotrebno u samom kernelu ,but who knows security pitanje iz dana u dan dobija na tezini.

Reci mi, ilaj, kako zamišljaš da se, kako ti kažeš, "aplikativno", ili preko "aplikacionog servisa", ili "skripticama" realizuje da kada ja ukucam (recimo omaškom, dešava se):



ostane sačuvana i prethodna verzija fstab-a?

U najboljem slučaju bi morao tweakuješ sistemske pozive kao što su open() ili creat() tako da obaveste tvoj "aplikacioni servis" da će fajl biti prepisan da bi taj servis mogao da sačuva prethodnu reviziju. A to opet znači modifikaciju kernela.

_{[Ovu poruku je menjao random dana 12.04.2006. u 23:36 GMT+1]}

Pa recimo koristeci monitoring prekida koji je zaduzen za HDD-ove.
Kada se aktivira pisanje po istom ta aplikacija(servis) prvo stopira proces pisanja na tom sektoru diska vidi koja tvoja aplikacija to zahteva procita sektor na koji to treba da bude upisano na osnovu toga i po nekim unapred zadatim kriterijumima odredi fajl koji se modifikuje ili brise kopira ga u memoriju ili na drugo mesto na disku(po nekim opet zadatim kriterijumima) ,nastavlja proces tvoje aplikacije i eto ti backupa i revizija.

Mislim u ovoj varijanti taj "aplikacioni servis" stalno slusa prekide upucene na hdd
i to ne zahteva modifikacije kernela a ne kao sto ti kazes da cuci u memoriji i ceka da bude obavesten(vec vidim analogiju sa nekim politicarima lol)
od sistemskih poziva da bi uradio svoj posao .

Naravno ovo je samo ideja onako iz glave ne moras da me drzis za svaku rec.

Za desktop korisnike sasvim je dovoljan i cron kada se dobro iskonfigurise(njega bar niko ne mora da obavestava sta se revizira ,brise itd, on pravi backup toga i toga tad i tad i cuva ih do koliko hoces).

Samo jedna stvar me zanima. Kakvi su to „prekidi upućeni na HDD“? (Mene su učili da se prekidi upućuju CPU-u). I preko kog interfejsa ih userspace program (taj tvoj servis) „sluša“? Molim detaljan odgovor.

I naravno, kako se implementira monitoring, a da nije obaveštavanje od strane kernela? Možeš da koristiš polling, da napraviš nešto slično SGI FAM-u (što je opet, nesrećno rešenje sa stanovišta performansi), ali nikako nećeš moći da pretekneš neku aplikaciju koja hoće, na primer, da resetuje fajl na veličinu 0. Onog trenutka kad tvoj servis stigne da stopira aplikaciju koja piše u fajl već je kasno, fajl deskriptor je već otvoren i fajl sistem drajver je već resetovao fajl. Znači taj pristup ne bi bio niti pouzdan, niti performantan (čitaj: ne može tako). A čak i da koristiš obaveštavanje od strane kernela (recimo preko već postojećih API-ja poput dnotify/inotify), ali opet, dok tvoj servis odreaguje, biće kasno.

_{[Ovu poruku je menjao random dana 13.04.2006. u 11:40 GMT+1]}

Ovako ,rekao sam da ne moras da me drzis za svaku rec ali evo:
u daljem textu pod aplikacijom smatraj proces koji zeli da upise nesto na HDD
a pod program-servis smatraj user skup procesa ili proces koji to kontrolise.
Naravno da kernel obavestava taj program-servis da se trazi upis na HDD ,za to nisu potrebne
nikakve modifikacije kernela ali:
1. kernel se moze konfigurisati da tom programu-servisu da najvecu mogucu instancu i prioritet,sta se time postize? Pa kada aplikacija posalje zahtev kernelu za pisanje kernel(preko CPU-a) to tumaci u vidu prekida zar ne e sada aplikacija od kernela ceka odobrenje zar ne ,kernel kada primi zahtev za upis interpretira to kao prekid obavestava o tome instancu i interfejs servisa-programa koja uzgred ima veci prioritet od aplikacije koja trazi upis ,program-servis kada je obavesten iz prve ruke u zahtevu za upis stopira ceo proces e sada tu su moguce dve varijante ili da vrati povratnu informaciju kernelu da kernel stopira proces ili da sam taj program-servis stopira(pauzira) datu aplikaciju(to necu sada razmatrati jer je analiza verovatno od par strana a ovo sto ja pisem je hipoteza).
2. Brzina datog procesa moze se obaviti u par ciklusa za koje kernel nema sanse da otvori
fajl deskriptor i inicijalizuje fajl sistem drajver (izracunaj).
3. Gde si ti procitao da su prekidi upuceni na HDD?
4. Odgovor na tvoje pitanje preko kog interfejsa se slusa kernel je ni preko jednog postojeceg.
Jednostavno ti napravis novi super optimizovani interfejs koji ce da u par ciklusa da primi obavestenje od kernela , i stopira aplikaciju ili to zatrazi od kernela a kada stopira onda proverava zadata pravila(cak ne mora da se ceka ni povratna informacija da je aplikacija stopirana jer mora biti, pa se odmah moze pristupiti analizi pravila).Nemoj mi samo reci da to ne moze da se napravi/napise.
5. Sustina je u tome da se kernel moze iskonfigurisati (bez njegovih izmena) da cim primi
odgovarajuci prekid posalje obavestenje gorepomenutom interfejsu pre nego sto pocne da otvara fajl deskriptor i drajver a i fajl deskriptor radi na manjem prioritetu od tog interfejsa.
6. E sada ostaje pitanje kako sve ovo realizovati.Pod pretpostavkom da se interfejs osluskivanja
moze napraviti moguce je u njega ugraditi i API kojim bi ti podesavao pravila a moguce je i sasvim zasebno napraviti API .
7. Analiza performansi ovog sistema je sasvim druga prica i nema veze sa pitanjem da li ovo moze da funkcionise ili ne .

Naravno verovatno su moguce varijacije ovog postupka radi optimizacije, kompatibilnosti i slicno.
Mislim ne zelim da ulazim u raspravu apsolutne fool-proof funkcionalnosti ovoga ali jednostavno mogu se navesti potrebni i dovoljni uslovi da bi dati postupak radio.

Sve ovo shvati kao hipotezu ja ne tvrdim da ovo radi ali kao i svaka hipoteza ona se moze argumentovano potvrditi ili argumentovano odbaciti ili naci potrebni i dovoljni uslovi i granicni uslovi funkcionalnosti.

Ja sam previse umoran da bih jos pisao o ovome ali ne zelim bez nepobitnih argumenata da verujem
da se ne moze bez modifikacije kernela spreciti nezeljeni upis podataka (bilo kakvom metodom).
Ako mi nepobitno dokazes da to nije moguce(ne samo ovo sto sam ja napisao vec uopste bez diranja kernela) sve sto sam napisao smatracu za spam i FUD .

Prioritet je nesto drugo, covece, u round robinu aplikacija koja ima visi prioritet dobija vise vremena.

To sto si opisao pod jedan (mada nema veze sa prekidima, tj interaptima), je kernel modul. A imas kernele koji su monolitni (nema modula), npr. FreeBSD, NetBSD.



A round robin covece? To se tako ne sme da budzi.



Pa mora da se modifikuje kernel, ako je modularni, sa ucitavanjem modula, ako je monolitni, sa rekompajliranjem.



_{[Ovu poruku je menjao bojan_bozovic dana 14.04.2006. u 01:13 GMT+1]}

Bojane ja u modifikaciju kernela ne racunam rekompajliranje i ucitavanje modula nego cackanje po sorsu i onda kompilaciju.Rekompajliranje je u ovom slucaju samo prilagodjavanje.U najgorem slucaju zalepiti patch kernelu.
Ma dosadilo mi je vise da se objasnjavam.

a da napravis patch ne treba sors ;-)

Bojane,
teorija je super stvar, ali čovek koji traži pomoć nema FreeBSD, čak ni NetBSD... Ima jednog običnog SuSe a, dakle, ako želite da mu pomognite budite konkretni....

ilaj, raspisi to (ili probaj) pa ces videti zasto je taj pristup neprihvatljiv (long-span, veliki tradeof usled udaranja u nekoliko nivoa apstrakcije, itd.)

ilaj, uopšte ne mogu da trošim vreme objašnjavajući



Ne. Sistemski poziv može biti (kod nekih OS-ova) implementiran kao softverski prekid, ali je to za ovu priču potpuno irelevantno.



Ne.



Kernel će resetovati fajl i zatim obavestiti aplikaciju. A obaveštavanje (inotify) je implementirano preko IOCTL interfejsa, što znači da bi servis morao da polluje neki device fajl u beskonačnoj petlji. Imao bi sve vreme aktivan proces sa visokim prioritetom koji zauzima 100% procesorskog vremena. Ako mi ne veruješ, probaj da napišeš.



Pa ne može proces sam da stopira drugi proces. Mora da traži od kernela da on to uradi. Ne poznaješ najosnovnije koncepte operativnih sistema.



Nema šta da računam, sve će se desiti pre nego što servis i stigne na red da primi taj event. Inače, fajl sistem drajver se inicijalizuje prilikom podizanja sistema.



Evo ovde:






Nisi shvatio pitanje, pitanje se odnosilo na interfejs KERNELA a ne na interfejs servisa. No nije bitno.



Kako može kernel kod da radi na manjem prioritetu od userland programa? :o) Pošto vidim da se mučiš sa nekim osnovnim konceptima, predlažem da nabaviš neku knjigu tipa "Osnove operativnih sistema" i pročitaš je.



Evo, nepobitan dokaz, na kontra-primeru gde takav pristup ne može da funkcioniše. Recimo da neki proces, na jednoprocesorskoj mašini, hoće da resetuje neki fajl na fajl sistemu, ovako:



Kada kernel dobije sistemski poziv, sistem radi u kernel-modu. Kernel će resetovati fajl jer se to zahtevalo (O_TRUNC), što podrazumeva izmenu i-node-a tog fajla. Zatim će proveriti u okviru tog istog i-node-a listu procesa koji treba da prime obaveštenje o modifikaciji fajla. Tek kada se ponovo pređe u user-mode, onda može da dođe na red tvoj servis (i to pod uslovom da mu je prioritet dovoljno visok, i da je baš on prvi sledeći proces u run queue-u schedulera) i da primi preko inotify interfejsa od kernela informaciju da je fajl izmenjen. Međutim u tom trenutku podataka više nema, tako da je svaki pokušaj da se zaustavi proces koji je uputio sistemski poziv u startu zakasnio. U najboljem slučaju tvoj servis će znati da je fajl izmenjen pre nego za to što sazna proces koji ga je izmenio, ali to je opet prekasno.



1) Mešaš koncepte -- to što je arhitektura kernela monolitna ne znači da on ne može da učitava module u run-time-u.
2) A pored toga, i FreeBSD i NetBSD imaju podršku za kernel module, tako da ni to nije tačno.

Ahem, greske se desavaju ;-)

Ala se društvo brzo razbežalo sa ove teme :o).