# SO Lista 9+2

## Zadanie 1
 <!-- Treść -->

### mount point
katalog znajdujący się w naszym systemie plików, który odwzorowuje innny system plików. Możemy mieć dostęp do plików zamountowanego systemu przez taki katalog

Mount pointy wyświetlamy `mount` (mounted file systems, mount point, mount options)
### pseudo-file system
system plików, który tak naprawdę nie ma w sobie plików, tylko daje nam takie przeczucie, że ma. Jądro generuje inormacje, które miałyby się w takim pliku znajdować i serwuje je do aplikacji

### Które to pseudo-file?
`mount | grep 'procfs\|sysfs\|debugfs\|configfs\|tracefs'`
<ul>
<li><b>/proc -></b>przechowuje info o działających procesach (procfs)</li>
<li><b>/sys -></b>dostarcza info o sterownikach, strukturach danych, podzespołach komputera itd. (sysfs)</li>
<li><b>/sys/kernel/debug-></b>stworzony dla programistów do debugowania aplikacji ("Można tam robić co się chce"~Wikipedia) (debugfs)</li>
<li><b>/sys/kernel/confing-></b>służy do przeprowadzenia operacji na obiektach jądra z userlandu (configfs)</li>
<li><b>/sys/kernel/tracing(?)-></b>używa się go do trackowania różnych rzeczy. Na przykład Ftrace używa go do przechowaywania danych do np. trackowania wywołań funkcji i eventów kernela. Też pełni funckję debugowania. (tracefs)</li>nodev
</ul>
### Atrybuty mount(8)
<ul>
<li><b>relatime-></b>zaaktualizuj czsa dostępu do inode wtw czas dostępu był wcześniej niż czas zapisu lub mody funkcji. Np. zmieniaj czas tylko na write di innode'a (przydatne jeśli dużo czytamy mało piszemy)</li>
<li><b>noexec-></b>odebranie prawa do wykonywania kodu binarek na zamontowanym systemie plików. Przydatne, gdy chcemy ograniiczyć niebezpieczeństwo związane z np. podłączeniem pendrive'a lub innego urządzenia USB do komputera</li>
<li><b>nodev-></b>system nie interpretuje plików blokowych i znakowych w systemie. Gdy tej flagi nie było to można by zrobić "kopie" naszego dysku z parametrami roota i zapisem dla wszytskich i wtedy popsuć nasz dysk np. z USB pendrive'a </li>
</ul>

<!-- notki -->

## Zadanie 2
 <!-- Treść -->
### Wzory
rozmiar bloku = 1024 << s_log_block_size
l1 i-nodeów w grupie bloków = s_inodes_per_group
l1 bloków w grupie = s_blocks_per_group
l1 wpisów tablicy deskryptorów grup bloków = s_blocks_count/s_blocks_per_group

### Składowe
<ul>
<li><b>blok-></b>plik dyskowy z ext2 jest podielony na małe sektory zwane blokami. Zazwyczaj mają 1,2,4 kilobajty</li>
<li><b>superblock-></b>przechowuje metadane o systemie plików. Główna kopia jest na offsecie 1024</li>
<li><b>grupa bloków-></b>bloki są złączone w grupę by dostęp był szybszy i powodował mniej fragmentacji. Info o każdej grupie jest w tabelach deskryptorów zaraz za superblokiem </li>
<li><b>tabela deskryptorów grup bloków-></b>opisuje zawartość i metadane wszytskich grup bloków. Ich kopia jest w parze z kopią superbloków</li>
</ul>


2 bloki zarezerwowane na bitmapę bloków w grupie i bitmapę inodeów w użyciu

Grupy 0,1 oraz kolejne potęgi 3,5,7 mają również kopię superbloków oraz tabeli deskryptorów

Reszta to bloki na dane. Superblok - 1 blok, tab. des. - liczba wpisów*size(wpis)

<!-- notki -->

## Zadanie 3
 <!-- Treść -->
### blok pośredni
array na blok danych (arraye bloków)

### synchroniczny zapis
wymuszone czekanie aż zapis nastąpi

### spójność systemu
zasady jakie stosujemy żeby system plików był spójny (slajdy z wykładu)

### dopisanie n bloków do pliku
1. Znajdź kolejny wolny blok na dysku i zapisz na bitmapie, że jest używany
2. Zlokalizuj i-node pliku
3. Spróbuj dopisać blok do direct bloków
4. Jeśli nie to do indirect-bloków (bo nie ma miejsca)
5. Jeśli direct jest za mały to stwórz strukturę do mapowania bloku*, doczep ją do inode, a następnie podczep liście indirect bloków do zaalokowanych danych (w tej kolejności)
6. W końcu podczep do inodea całą strukturę mappingu wraz z danymi i zupdatuj metadane inodea
7. Powtarzaj od 1. dla next n-1 bloków

(*) Chodzi o to żeby po kolei od liści do korzenia zaalokować strukturę indirect bloków dla nowych danych (W tej kolejności by uniknąć kłopotów z awarią)
<!-- notki -->

## Zadanie 4
 <!-- Treść -->
### atomowo
operacja wykonuje się cała albo w ogóle się nie wykonuje

### czemu rename zakończy się EXDEV
nie ma to sensu, bo nie mamy prawa dokładnie wiedzieć na jaki sys. plików przenosimy, może mieć zupełnie inną strukturę i implementację (np. inodeów). Nie można tak po porostu "zrzutować" struktury inodea i liczyć, żę zachowamy spójność

### Przenoszenie pliku między katalogami
1. Jeśli dostaniemy nazwę pliku to żeby dostać abs. path to bierzemy cwd użytkownika i złączamy z nazwą. Wtedy po serii chodzenia po kolei po inodeach ścieżki dostaniemy się do inodea pliku, który mamy przenieść i też katalogu docelowego
2. Jak już namierzymy nasz rekord katalogu źródłowego to z poz. rec_len mamy size rekordu. Kopiujemy go
3. Teraz szukamy miejsca w destination
<ul>
<li>Jeśli znajdziemy rekord, gdzie inode == 0 i rozmiar >= rozmiar naszego pliku to essunia -> ctrl+c ctrl+v</li>
<li>Jeśli nie ma miejsca to idziemy na koniec katalogu i tam go wrzucamy (alignujemy do size(blok) jeśli się nie zmieścimy w poprzednim</li>
</ul>
(To było gdzieś totalnie w innym miejscu ale wydaje się mieć sens)
4. Aktualizujemy rec_len poprzedniego rekordu, żeby pointował na nasz rekord
5. W źródłowym inodzie wpisujemy 0 (w katalogu skąd braliśmy plik)

<!-- notki -->

## Zadanie 5
 <!-- Treść -->

### Kiedy możliwe jest odwrócenie usunięcia pliku?
1. Jeśli plik miał >= 2 hardlinki do niego. Wtedy jest gdzieś jakiś plik pointujący na niego w fsie (file system)
2. Można go odzyskać jeśli jego rekord na dysku nie został nadpisany przez coś innego

### Kiedy plik zostanie faktycznie usunięty z dysku?
Kiedy nadpiszemy jego blok
Usuwanie pliku z katalogu
1. Bierzemy inode tak samo jak w 4.1
2. Zmniejszami i_links_count o 1 i inode w entry katalogu dajemy na 0 (nie samego inode tylko jego rekord)
3. Jeśli i_links_count > 1 to fajrant
4. Inaczej jeśli istnieją jakieś otwarte deskryptory to nie usuwamy aż się zamkną
5. Potem w bitmapie inodów wpisujemy 0 temu co usuwamy. Następnie (zajmujemy?) (nie rozumiem) w bitmapie bloków bloki tego inodea, które zajmuje i na końcu updatujemy superblock

<!-- notki -->
## Zadanie 6
 <!-- Treść -->
### hard link
pointer na inode, jedynie może zmienić się nazwa pliku w katalogu
### symbolic link
specjalny plik który wskazuje na inny plik. Zawiera absolutną ścieżkę do pliku

### Co robi ext2 przy tworzeniu linków?
#### hard link
tworzy rekord w katalogu i pointuje i-node do już istniejącego (tego do którego linkujemy) i zwiększa i_links_count w i-nodzie
#### symbolic link
tworzy rekord w katalogu i tworzy nowy i-node z polem i_node mówiącym, że jest to symlink. Do tego pliku wrzuca ścieżkę do wskazywanego pliku (I guess)
### Jak stworzyć pętlę
ln -s link_2 link_1
ln -s link_1 link_2
### Kiedy jądro systemu operacyjnego ją wykryje i zwróci błąd ELOOP?
Max symlinków (?) jądro zdereferensuje to 40 więc 41 zwróci ELOOP <!-- [szczerze nie rozumiem o chuj chodzi xD] -->
### Czemu pętli nie da się zrobić hardlinkami?
bo są bezpośrednie, tzn. pointują na inode, a nie na rekord katalogu

<!-- notki -->
## Zadanie 7
 <!-- Treść -->

### Czemu fragmentacja systemów plikó jest szkodliwym zjawiskiem?
Większy czas oczekiwania na odczyt pliku, bo głowica dysku musi szybko się przemieszczać tam i z powrotem
### Odroczony podział bloków
alokowanie bloków nie następuje od razu tylko jest odraczane aż do momentu zflushowania bufforu stron na dysk. Wtedy jak alokujemy to zwiększamy szanse na to, że bloki pliku będą koło siebie -> zmniejszenie fragmentacji
### Zakresy
efektywna struktura zaimplementowana w ext4. Mapuje logiczne do fizycznych bloków (pewnie chodzi o adresy) w taki sposób, że potrafi zaadresować wiele ciągłych w pamięci bloków (max 2^15 bloków). W ext3 mamy direct mmapping taki, że 32 bit address -> 1 blok, poza tym mamy też double - indir. i 3-indirect co znacznie zwiększa potrzebę na metadane. Zakresy dobrze współgrają z odroczonym przydziałem bloków


### Czy po defragmentacji systemu plików ext4 liczba wolnych bloków może wzrosnąć?
tak, bo wtedy extenty będą mogły po prostu zwiększyć size w strukturze i zwolnić resztę nieużywanych struktur (że będą na więcej bloków pointowały)
### Jak mógłby wyglądać najprostszy algorytm defragmentacji?
ext4 robi to tak, że tworzy tmp i-node i alokuje ciągłe zakresy dla niego, wpycha bloki danego pliku do page_cache i flushuje je do tego inode. Na końcu przepina wsk. oryginalnego inode z tym tymczasowym

<!-- notki -->
## Zadanie 8
 <!-- Treść -->
Zamieniłem <> na [] bo jakieś problemy miał
debugfs [partycja]
1. wpisz free frag potem stat i opowiedz
2. dump_extents [plik]
3. np. $dump_extents /bin/sudoedit
widać, że nie używa extends, więc content przetrzymywany w inodzie (block_dump)
4. blocks [plik] -> [block]
icheck [block] -> [inode]
ncheck [inode] -> [plik]
5. blocks [katalog] -> [block]
block_dump [block]

<!-- notki -->

## Zadanie 9 (bonus)
 <!-- Treść -->


https://www.kernel.org/doc/html/v4.19/filesystems/ext4/ondisk/index.html

## Zadanie 10 (bonus)
 <!-- Treść -->