[so2] [Tema 4] Formulare gresita in enunt

[Cristian Chilipirea]

On Tue, May 1, 2012 at 2:57 PM, Razvan Deaconescu <
razvan.deaconescu at cs.pub.ro> wrote:

> Bogdan Purcareata <bogdan.purcareata at gmail.com> writes:
> > Salut,
> >
> > Din enuntul temei:
> >
> > "data_blocks este un vector (cu dimensiunea precizată in superbloc)
> > care indică numerele blocurilor de date relativ la zona de date;
> > intrările nefolosite trebuie setate pe 0 (adică dacă avem un fișier cu
> > dimensiune 2050 și dimensiunea blocului de 1024 atunci vom avea
> > primele trei valori din vector strict pozitive și restul 0)" (in
> > structura pitix_inode).
> >
> > Daca numerele blocurilor sunt relative la zona de date, atunci va
> > exista si un bloc cu numarul 0, care este valid.
>

Corect! Dar  blocul cu numarul 0 este atribuit primului director, mereu.
"Directorul rădăcină va avea alocat inode-ul 0 și blocul de date 0. "


> > Enuntul ar trebui sa
> > specifice ca determinarea numarului de blocuri folosite de un inode sa
> > se bazeze exclusiv pe dimensiunea fisierului / directorului
> > (inode->i_size) si dimensiunea blocului, asa cum este specificata in
> > superblock (sp->s_blocksize).
>

Da ar trebui sa se bazeze  SI pe asta.

De ce merge totusi asa cum era enuntul in modul intial?
Directoarele se trateaza un pic diferit fata de fisiere.
La directoare am mereu incredere ca blocul [0] este un bloc corect, oricare
ar fi el.
Cum este in cazul directorului radacina, el poate pointa chiar si spre 0 si
asta e ok.

Fisierele in schimb oricum nu pot sa foloseasca blocul 0 pentru ca acesta e
rezervat pentru radacina.
Ergo... orice fisier care are blocuri ce pointeaza spre 0 ar trebui sa
putem considera ca acestea nu exista.


> Salut, Bogdan!
>
> Am făcut corecțiile pe care le-ai indicat tu.
>
> Răzvan <http://elf.cs.pub.ro/so2/wiki/resurse/lista-discutii>


Nu cred ca era nevoie de corectii.
E important sa ne folosim de inode->i_size dar ne putem al fel de bina baza
si pe blocuri ce pointeaza spre 0.

Cu stima,
Cristian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so2/attachments/20120501/23372382/attachment.htm>