2015-05-13 0:24 GMT+03:00 Alex 'CAVE' Cernat <[email protected]>: > On 12/5/2015 11:47 PM, Sîrbu Lucian wrote: > > Nu poti sa faci un cron care muta fisierele mai vechi de X zile pe alta > > partitie? > > Stiam de undeva ca un fs devine mai lent cu cat are mai multe inode-uri > > ocupate. > > > > bingo, ai pus punctul pe "u": "fisierele mai vechi", FARA sa scanez tot > filesystem-ul, si fara sa ma joc cu altceva decat cu filesystem-ul > > fs-ul devine mai lent din cauza fragmentarii, va trebui sa scrie / > citeasca din mai multe locuri, ceea ce la dispozitivele rotative (aka > harduri clasice) nu face bine la ten; la ssd-uri penalitatea e mult mai > mica, s-ar putea chiar neglijabila > > Cred ca suferi de ceea ce in limbajul de specialitate se cheama un costinism ;) Nu prea ai cum sa implementezi ceva de genul asta pt. date generice, singurele structuri de date similare pe care le stiu sunt round-robin databases ca RRD sau Whisper (din graphite), si trickul care le permite sa functioneze e ca datele sunt de dimensiune fixa astfel incat sa le poata calcula direct adresa si sa minimizeze seek times, dar nu cred ca workloadul tau e atat de specific (si ca mai degraba rezolvi asta din aplicatie, cu un layer de indexare, dar nu e asa de transparent pe cat ti-ai dori).
Acum ca zic asta, mi-aduc aminte ca am citit undeva in tinerete de conceptul de log-structured FS, care practic asta face, round-robin storage, dar nu sunt sigur ca implementarile conceptului iti rezolva tie problema. JFFS2 si altele ca el sunt gandite in principal pt. wear-leveling pe ssd-uri si nu ca sa reduca seek times, iar NILFS tin minte ca a fost gandit cu gandul la performanta si reliability la scriere. Posibil ca in workloaduri foarte specifice sa-ti rezolve problema, dar din cate povestesti tu, solutia de care ai cu adevarat nevoie e sa inveti aplicatia aia sa foloseasca explicit un cache, nu sa abuzezi un fs sa se comporte ca un cache. Da' daca insisti sa sufli in bujii de OZN-uri, fa si documentatie, filmulete etc, macar sa stim si noi astia mai mainstream ce ratam. -- P. _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
