mount-cache sneller refreshen

[Verwijderd]

Hallo,

Hoop dat de titel een beetje duidelijk overkomt maar ik zit met het volgende :

Heb in onder linux (fedora4) qemu draaien die een gewoon raw bestand gebruikt als partitie (fat32) nu mount ik dit bestand gewoon als loopback zodat ik er in linux met clamav overheen kan gaan voor eventuele virussen. Dit lukt allemaal fantastisch het enige nadeel is dat de cache niet gerefreshed wordt van de inode's. Met als gevolg dat als ik in windows 2000 een map of bestand aanmaak maar die in linux nog niet kan zien omdat het zooitje daar nog niet geupdate is.

Mijn vraag : is het mogelijk het cachen bijvoorbeeld elke 5 a 10 seconde te laten doen zodat alles meer consistent is? Ik neem aan dat het op kernel niveau zowieso wel te doen is maar in welke bestanden wordt dit mechanisme geregelt?

Heb uitteraard gegoogled en al op tweakers gekeken maar ben niet veel tegengekomen (wellicht door verkeerde zoekcriteria).

Alle suggesties zijn welkom

[_JGC_]

Hmm, je laat dat raw bestand dus zowel door qemu gebruiken als door linux dmv een loopmount... vind je het vreemd dat dat verkeerd gaat? Valt mij nog mee dat je nog niets van data corruptie gemerkt hebt.

[Verwijderd]

Yep inderdaad, in linux heb ik trouwens alleen read only nodig het is niet de bedoeling dat clamav de bestanden die geinfecteerd zijn verwijdert op iets dergelijks...

[JeroenE]

Eerst even indekken: Ik heb geen verstand van qemu.

Weet je zeker dat het probleem aan de linux kant zit?

In linux kan je (in ieder geval ext2 en ext3) mounten met de optie "sync" die er voor zorgt dat alle wijzigingen gelijk worden weggeschreven ipv opgespaard tot het systeem even niets aan het doen is.

Het zou mij niet verbazen als een dergelijke feature in Windows zit en dat de FAT-entries gewoon nog niet geupdate zijn. Het is alleen de vraag of je in je geemuleerde windows iets aan kan zetten wat er voor zorgt dat dit wel gebeurt (ik weet niet eens of je dat ueberhaupt aan kan zetten).


Ik kan me echter voorstellen dat een filesystem-driver er niet vanuit gaat dat een ander proces hetzelfde filesystem aan het beschrijven is en dat het 'probleem' dus wel in linux zit. Waarom mount je niet gewoon vlak voor dat je gaat scannen en unmount je weer als je klaar ben? Je hebt dan wellicht niet alle directories gescanned (namelijk die aangemaakt zijn tijdens het scannen), maar die komen de volgende keer wel mee.

[Wilke]

2x tegelijk in hetzelfde FS zitten prutsen lijkt me vragen om problemen.

Overigens heeft VFAT geen inodes, hoe het wel precies werkt weet ik niet, maar in ieder geval lijkt het me dat je het scannen beter niet kunt doen terwijl Windows ook nog draait in qemu? Read-only scheelt al veel, maar dan kan het nog steeds gebeuren dat Windows net het halve FS verandert (bv. omdat je net een directory verwijdert ofzo) terwijl je met ClamAV die directory probeert te scannen - gaat vast ook niet zo goed...

[Verwijderd]

jeroene schreef op dinsdag 22 november 2005 @ 14:17:
Eerst even indekken: Ik heb geen verstand van qemu.

Weet je zeker dat het probleem aan de linux kant zit?

In linux kan je (in ieder geval ext2 en ext3) mounten met de optie "sync" die er voor zorgt dat alle wijzigingen gelijk worden weggeschreven ipv opgespaard tot het systeem even niets aan het doen is.

Het zou mij niet verbazen als een dergelijke feature in Windows zit en dat de FAT-entries gewoon nog niet geupdate zijn. Het is alleen de vraag of je in je geemuleerde windows iets aan kan zetten wat er voor zorgt dat dit wel gebeurt (ik weet niet eens of je dat ueberhaupt aan kan zetten).


Ik kan me echter voorstellen dat een filesystem-driver er niet vanuit gaat dat een ander proces hetzelfde filesystem aan het beschrijven is en dat het 'probleem' dus wel in linux zit. Waarom mount je niet gewoon vlak voor dat je gaat scannen en unmount je weer als je klaar ben? Je hebt dan wellicht niet alle directories gescanned (namelijk die aangemaakt zijn tijdens het scannen), maar die komen de volgende keer wel mee.

Bedankt voor de reacties tot nu toe

Jeroen het licht 100% zeker aan de linux kant de windows kant heeft er weinig mee te maken die weet niet eens dat het FS ook nog voor andere doeleinden gebruikt wordt. en de sync optie zou weinig invloed hebben omdat het read-only is geen veranderingen in het FS zelf maakt, volgens mij kan sync ook niet met vfat naar mijn weten

Scannen gaat tot nu toe perfect omdat het fs nagenoeg niet gerefreshed wordt. Dus geen problemen met het sharen van het FS zelf.

Ik geef toe dat het inderdaad om problemen vraagt deze aanpak. Andere ideen zijn natuurlijk ook welkom, heb zelf ook al over netwerk scannen gedacht maar dit is zowieso te traag en is geen optie omdat de windows gebruiker niets mag weten dat het gescanned wordt.

[_JGC_]

Windows doet wel degelijk caching. Op het moment dat jij iets wegschrijft in Windows, wil dat nog niet zeggen dat dat daadwerkelijk ook op het filesystem fysiek staat. Verder is linux gewend om gewoon een filesystem te mounten, te kijken hoe dit eruit ziet en vervolgens wordt er alleen via de VFS layer mee gewerkt. Als ondertussen een of ander persoon dan de onderliggende partitie gaat aanpassen, weet linux daar niets van, aangezien die nooit kan weten dat ineens de FAT is veranderd.

[Steven]

Zover ik weet doet Windows niets aan caching van te writen data. Dat is ook de reden dat je floppydrive bij Windows altijd meteen begint te ratelen bij kopieren en bij Linux niet.

[JeroenE]

Verwijderd schreef op dinsdag 22 november 2005 @ 17:47:Jeroen het licht 100% zeker aan de linux kant de windows kant heeft er weinig mee te maken die weet niet eens dat het FS ook nog voor andere doeleinden gebruikt wordt. en de sync optie zou weinig invloed hebben omdat het read-only is geen veranderingen in het FS zelf maakt, volgens mij kan sync ook niet met vfat naar mijn weten

Windows heeft er wel zeker mee te maken. Die is toch degene die het filesystem aanpast? Zolang windows de veranderingen in het geheugen heeft staan kan linux daar natuurlijk nooit wat mee doen. Maar zoals _JGC_ al zegt zou het weinig uitmaken omdat linux niet iedere keer de FAT gaat lezen omdat er niet verwacht wordt dat iemand anders er ook op schrijft.

Voor degene die niet geleoven dat windows een filesystem cache heeft heb ik met 3 seconden googlen een eerste link gevonden. Als je meer info wil weten dan kan je het misschien beter in WOS vragen. Er is een reden waarom je bijvoorbeeld USB-apparaten altijd eerst met 'veilig verwijderen' moet "unmounten".

is geen optie omdat de windows gebruiker niets mag weten dat het gescanned wordt.

Waarom niet? Ik zou gewoon de virusscanner in de emulatie installeren.

[Verwijderd]

jeroene schreef op donderdag 24 november 2005 @ 08:52:
[...]
Windows heeft er wel zeker mee te maken. Die is toch degene die het filesystem aanpast? Zolang windows de veranderingen in het geheugen heeft staan kan linux daar natuurlijk nooit wat mee doen. Maar zoals _JGC_ al zegt zou het weinig uitmaken omdat linux niet iedere keer de FAT gaat lezen omdat er niet verwacht wordt dat iemand anders er ook op schrijft.

Voor degene die niet geleoven dat windows een filesystem cache heeft heb ik met 3 seconden googlen een eerste link gevonden. Als je meer info wil weten dan kan je het misschien beter in WOS vragen. Er is een reden waarom je bijvoorbeeld USB-apparaten altijd eerst met 'veilig verwijderen' moet "unmounten".


[...]
Waarom niet? Ik zou gewoon de virusscanner in de emulatie installeren.

Ik weet dat windows een filesystem cache heeft, het gaat er gewoon om dat het voor linux niet zichtbaar is dat het fs ook nog voor andere doeleinden gebruikt wordt.

En de virusscanner moet buiten de emulatie plaatsvinden, het beveiligen moet zoveel mogelijk los staan van de windows installatie.