Що не потребує дефрагментації? Linux або ext2 ext3 FS?

Чому вам не доведеться дефрагментувати систему Linux? Тому що він використовує файлову систему ext2 / ext3 або тому, що це Linux?

Це актуально, оскільки у мене є система подвійного завантаження (W7 / Ubuntu) і загальний розділ (NTFS), до якого можна отримати доступ обома системами. Якщо я використовую цей розділ з Linux, він стане фрагментованим?

Інша проблема - контейнери Truecrypt. Я також отримую доступ до них за допомогою Linux та Windows, і вони є FAT32. Вони розбиваються на Linux, який працює на них?

Ось стаття про те, як Geek про те, як ext2 / ext3 виділяє файли на диску. А також у них є стаття із запитанням: " Вам справді потрібно дефрагментувати ?"

Про те, чому FAT стає фрагментарним:

"Коли ви зберігаєте файл у файловій системі FAT, [файл зберігається] якомога ближче до початку диска. Коли ви зберігаєте другий файл, [файл зберігається] відразу після першого файлу - і так Коли оригінальні файли збільшуються у розмірі, вони завжди стануть фрагментованими. Поблизу немає місця, в яке вони можуть перерости. "
-Як Geek

А у wikipedia більше інформації про фрагментацію FAT .

Як розподілити файли EXT2,3,4:

"Файлові системи ext2, ext3 та ext4 [...] виділяють файли більш розумним способом. Замість розміщення декількох файлів поруч один з одним на жорсткому диску, файлові системи Linux розкидають різні файли по диску, залишаючи велику кількість вільного простору між ними ».
-Як Geek

(І більше інформації про дефрагментацію на ext3, з wikipedia )

"Сучасна файлова система Linux підтримує фрагментацію як мінімум, зберігаючи всі блоки у файлі близько один до одного, навіть якщо вони не можуть бути збережені в послідовних секторах. Деякі файлові системи, наприклад ext3, ефективно виділяють вільний блок, найближчий до інших блоків у файлі. Тому не варто турбуватися про фрагментацію в системі Linux. "
- TLDP

Фрагментація - це завжди турбота незалежно від файлової системи. Однак Ext3 / Ext2 мінімізували проблему до того, що більшість адміністраторів просто працюють так, ніби це не викликає проблем. Це зводиться до мінімуму за допомогою грамотного планувальника вводу-виводу та файлової системи, що залишає простір після кожного файлу для зростання. Крім того, додаткові фрагменти зберігаються ближче один до одного, тому навіть коли є фрагментація, ефекти сильно приглушені. Переключення Ext4 на екстенси також було покликане допомогти ще більше пом'якшити фрагментацію.

Фрагментація все ще існує, у ext2 був інструмент дефрагментації в режимі офлайн, ext4 отримує онлайн-файл, а btrfs (тільки тому, що це пов'язано з питанням) вже має онлайн-дефрагментацію. Якщо ви перебуваєте на ext3, ваш єдиний реальний вибір - це перетворити на ext4 (через tune2fs) або спробувати дізнатися, яка кількість удачі вам належить до таких інструментів для користувацького простору shake.

Залежно від типу вводу / виводу, у якому працює ваша файлова система, це все ще може викликати занепокоєння навіть на її приглушеному рівні, тому інтернет-інструменти вважалися корисними для початку.

Що стосується питання про FAT32, фрагментація не відбувається, коли ви просто працюєте над файлом, це відбувається, коли ви пишете у файл. Щоб безпосередньо відповісти на ваше запитання, фрагментація є аспектом дизайну файлової системи, тому ваша файлова система FAT32 має потенціал до фрагментації, коли ви щось на неї пишете.

Відповідаючи на ваші запитання, по черзі:

Чому вам не доведеться дефрагментувати систему Linux? Тому що він використовує файлову систему ext2 / ext3 або тому, що це Linux?

Оскільки ext2 / 3/4 мають інший підхід щодо файлів і папок, тому вони ледве роздроблені. Інші вже відповіли про це, і більше деталей ви можете прочитати тут

Це актуально, тому що мають подвійну завантажувальну систему (W7 / Ubuntu) і загальний розділ (NTFS), до якого може бути доступна обидві системи. Якщо я використовую цей розділ з Linux, він стане фрагментованим?

Так, він може роздроблено. Справа не в тому, якщо до нього звертається Windows, Linux чи щось інше, це те, як кожна файлова система має справу з розміром файлу, як зберігає всі ці блоки, чи залишає порожні пробіли між кожним файлом ...

Інша проблема - контейнери Truecrypt. Я також отримую доступ до них за допомогою Linux та Windows, і вони є FAT32. Вони розбиваються на Linux, який працює на них?

Контейнери Truecrypt - це файл для всіх практичних питань. Коли ви створюєте контейнер за допомогою TrueCrypt, ви створюєте файл потрібного розміру. Для вашої операційної системи це як і будь-який інший файл. Якщо ви робите його копії тощо, можливо, копії можуть бути збережені фрагментарно.

Але пам’ятайте, що ніколи не є корисним мати кілька копій одного контейнера, це може допомогти знизити безпеку цього контейнера. Завжди робіть новий контейнер.

Коли ви зберігаєте, видаляєте, копіюєте, переміщуєте тощо файли всередині контейнера, операційні системи про це не знають, це ж відкриття, редагування та збереження будь-якого іншого файлу, не змінюючи його розмір.

І якщо ви переживаєте за безпеку truecrypt щодо фрагментації, зробіть кілька досліджень щодо використання truecrypt з SSD: оскільки SSD намагається зменшити знос всієї пам'яті всередині нього, ви можете мати такий же ефект від копіювання контейнера навколо.

Зрештою, справа до драйверів файлової системи в ОС.

Файлові системи ext2 і FAT - це обидва способи запису, які блоки на диску належать до якого файлу. Якщо не всі блоки файлу є суміжними, файл називається фрагментованим. Але як очевидно, фрагментація спричинена стратегією розподілу блоку під час запису файлу, а не тим, як ви записуєте ці блоки.

Що має значення - це наскільки далеко вперед можуть виглядати драйвери файлової системи. Якщо водій знає, що є ще 10 блоків для запису, він може вибрати суміжну вільну область і уникнути подальшої фрагментації. Це залежить від архітектури драйвера, що залежить від ОС. Але той самий пошук вільного простору можна виконати на FAT та ext2.

Насправді, ext2 і FAT насправді не такі різні, як ви можете подумати. Я написав ext2 частину завантажувача поверх існуючого коду FAT, і для цього потрібно менше 100 додаткових рядків коду.