On Wed, 20 Feb 2002, Linux User wrote: > Am un system pe care doresc sa pun jurnalizare. De fapt, problema ar fi cam > asa: Cam care are fi varianta optima de a imbina mai multe sisteme cu > jurnalizare pe acelasi sitem. Si cind spun asta, ma gindesc la urmatoarele. >
Cauta pe google dupa linux journaled filesystems si dai peste cateva analize asupra variantelor existente in acest moment. > Initial, am avut urmatoarea structura, cu care am avut probleme: > > partitie /boot - ext2 > partitie / -reiserefs > > In partitia / (radacina) am: > in /usr/local/mysql Mysql-ul si in /usr/local/Apache Webul. > in /home/squid Squidul > in /var/qmail Qmailul. > La un moment dat, mi-a cazut curentul si cind am repornit masina, > resiserul mi-a busit citeva fisiere: A schimbat ceva caractere prin > /etc/inetd.conf si in /var/spool a redenumit dirul cron in cr20n si dirul > mail in ma!l . De unde am inteles ca nu este deloc bine asa. > LOL. Man cred ca faci o confuzie. Sistemele jurnalizate "normale" NU iti jurnalizeaza si datele ci doar metadatele (adica datele din inode, dimensiune, timestamps, owner etc...). Deci depinzand de tipul de fs date SE pierd atunci cand datele nu au ajuns pe disk si a facut crash. Sistemul jurnalizat iti garanteaza doar ca la reboot intr-un timp foarte mic iti aduce fs-ul intr-o stare "corecta". > Acum m-am decis: > > o sa fac o partitie separata /home pe care o sa pun reiserfs din motive de > Squid, pe /boot o las ext2, /usr/local va fi si ea o partitie separata dar nu > stiu ce sitem de fisiere sa-i pun din cauza mysql-ului. > Si daca pica curentul si datele care se scriau pe ext2 nu au ajuns pe disk nu numai ca stai sa faca fsck dar dupa ce termina TOT "ai pierdut" date asa cum te exprimi tu. > La fel o sa fac si cu /var, care va fi si ea o partitie separata. > > Ce se intimpla cu baza de date a MySql-ului daca este pusa pe un sistem cu > jurnalizare, si in acest timp, din diferite motive, masina este oprita brusc? > Ce se intimpla cu tranzactiile care erau facute in acel moment? As dori cumva > o solutie prin care, chiar daca se pierd anumite tranzactii, sa nu mi se > busasca toata baza de date. > Well ce se intampla este ca se poate intampla orice. Depinde de mysql, de linux si de fs dar teoretic orice se poate intampla. O solutie ar fi ca la shutdown sa scrii un fisier undeva si cand pornesti sa-i verifici existenta si sa-l stergi ca sa stii daca ai pornit in urma unui crash sau a unui boot normal, iar in caz de crash sa rulezi un script perl care iti face check/repair pe toate tabelele mysql-ului. > La fel si cu /var -ul. Qmailul este patchuit pentru a stii sa lucreze cu > reiserfs, dar daca se hotaraste ca in /var va putea fi un alt sistem de > fisiere, tre sa stiu exact care sunt necazurile pe care le pot avea cu > Qmailul. > breh eu nu am patchuit nici un qmail si mi-a mers pe reiserfs fara probleme. de fapt cred ca patchuil tau asigura link/unlink sa fie sincron (asta e cerinta qmail-ului de la un fs) dar in principiu orice fs jurnalizat metadata are link/unlink sincron (in ideea ca daca nu modifica pe disk macar modifica in jurnal). > Ma gindeam la XFS dar nu am lucrat cu el. Imi puteti face sugestii despre o > structura optima a raportului partitii(mount > point)/sitem-fisiere-cu-jurnalizare? > Breh Alex daca tu vrei sa NU pierzi date montezi fie cu sync fie pui ext3 si -o data (adica sa jurnalizeze si datele) dar in ambele cazuri performantele sunt muci daca ai multe modificari pe fs... ---------------------------- Mihai RUSU "... and what if this is as good as it gets ?" --- Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to unsubscribe from this list.
