s
При необходимости освободить дропнет чистые страницы и постарается засинкать грязные
Size: a a a
2020 April 02
Т
Это фактические данные из inode vfs, прочитанных с диска
Но это не фактический бинарник, мне же утверждали что это работает по прицепу preload
s
Но это не фактический бинарник, мне же утверждали что это работает по прицепу preload
Это фактическая копия данных с диска.
Т
Не уверен на счёт этого
t
Но это не фактический бинарник, мне же утверждали что это работает по прицепу preload
никто такого не говорил
s
То есть ядро может часть inode не читать в память с диска, они там уже валяются
t
говорили, что есть кэш в озу, который хранит данные с диска
Т
То есть ядро может часть inode не читать в память с диска, они там уже валяются
Да это так, но это не одно и тоже
s
на первом диске, первый раздел к примеру 30GB для корня, второй раздел для home 70GB.
второй диск весь 100GB и двум subvolume доступно все 100GB как рут так хоме.
второй диск весь 100GB и двум subvolume доступно все 100GB как рут так хоме.
опана. этого я не знал.
t
а особенности имплементации уже не важны
Т
говорили, что есть кэш в озу, который хранит данные с диска
Нет , говорили что есть кэш в озу который хранит мой терминал
s
Да это так, но это не одно и тоже
В смысле? Это снимок данных
t
Нет , говорили что есть кэш в озу который хранит мой терминал
так твой терминал это и есть данные с диска
t
как бы disk cache намекает на это
t
в названии уже подсказка
Т
В смысле? Это снимок данных
Смысл в том, что во время работы процесс (данные) не полностью эквивалентен данным на диске?
Т
Только часть
t
процесс не является данными на диске
Т
С точки зрения памяти всё данные
WA
опана. этого я не знал.
примерно так:
[wolf@arch-pc ~]$ df -h | grep /dev/sda
/dev/sda3 212G 41G 170G 20% /
/dev/sda3 212G 41G 170G 20% /home
[wolf@arch-pc ~]$ df -h | grep /dev/sda
/dev/sda3 212G 41G 170G 20% /
/dev/sda3 212G 41G 170G 20% /home