ext3 fsck час порівняно з розміром розділу


9

Я роблю налаштування для масштабної ферми зберігання, і щоб уникнути необхідності місячних fscks, мій план полягає в тому, щоб розділити сховище на численні менші файлові системи (це добре, оскільки у мене є добре забудоване дерево файлів , так що я можу легко мати окремі файлові системи змонтовані на 1/, 2/, 3/, 4/і т.д.).

Моя складність полягає в пошуку будь-якого перерахування того, що "розумний" розмір для файлової системи, щоб зберегти fsck рази аналогічно "розумним". Хоча я цілком усвідомлюю, що абсолютний час для заданого розміру багато в чому залежатиме від обладнання, я не можу знайти жодного опису форми кривої для ext3 fsck разів із різними розмірами файлової системи та якими є інші змінні ( чи файлова система, повна файлів в одному каталозі, займає більше часу, ніж одна, з 10 файлами в кожному з тисяч каталогів у дереві; великі файли проти малих файлів; повна файлова система проти порожньої файлової системи тощо).

Хтось має посилання на якісь добре вивчені номери з цього приводу? Якщо цього не зробити, будь-які анекдоти з цих питань повинні, принаймні, допомагати керувати моїми власними експериментами, якщо це потрібно.

EDIT : Щоб уточнити: незалежно від файлової системи, якщо щось не вдається з метаданими, це потрібно буде перевірити. Увімкнено чи потрібні повторні фс-коди на основі часу або на монтажі, не викликає сумнівів, і єдина причина, яку я запитую для номерів конкретно щодо ext3, це те, що це найвірогідніша файлова система, яку слід обрати. Якщо ви знаєте про файлову систему, яка має особливо швидкий fsck процес, я відкритий для пропозицій, але це дійсно повинно бути надійним варіантом (стверджує, що "файловій системі X ніколи не потрібен fscking!" Буде сміятися і висміюватися в довжину) . Я також усвідомлюю необхідність створення резервних копій, і бажання fsck не є заміною резервного копіювання, однак просто відкидання файлової системи та відновлення з резервного копіювання, коли вона глючить, а не перевіряє її, здається, справді,

Відповіді:


6

Згідно з документом Mathur et al. (стор. 29), час e2fsck лінійно зростає із кількістю входів у файловій системі після певного моменту. Якщо графік буде що-небудь пройти, ви ефективніші з файловими системами до 10 мільйонів входів.

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


Дякую за довідку, допомогла підтвердити кілька речей для мене. Я також здійснив власний бенчмаркінг, який показав лінійне зростання, показане в цій статті.
живіт

2

Я думаю, вам доведеться робити власний бенчмаркінг. Швидкий пошук в Google не виявив нічого, крім того, що ext4 fscks набагато швидше, ніж ext3.

Отже, створіть кілька розділів ext3, 100 ГБ, 200 Гб тощо, до розміру диска, який ви будете використовувати. Потім заповніть їх даними. Якщо ви можете використовувати дані, що нагадують ваші виробничі дані (файли в каталозі, розподіл розмірів файлів тощо), тоді це буде найкраще. Зауважте, що просто копіюючи файли з іншого пристрою резервного копіювання, вони розмістять їх на диску ідеально викладеними та дефрагментованими, і тому ваші тести не матимуть великої кількості головок диска, які шукатимуть часу, що прийде від великої кількості запису / зміни / видалення.

Вам також потрібно буде подумати про паралельні fscks. Перегляньте останні пару полів у / etc / fstab. Розділи на одному фізичному диску слід робити послідовно; кілька дисків на одному контролері можна робити паралельно, але слідкуйте за тим, щоб не перевантажувати контролер і уповільнювати їх.


0

http://lmgtfy.com/?q=fsck+benchmark

схоже, що fsck у файлових системах ext4 значно швидший, ніж у ext3, при цьому деякі повідомлення про ext4 fsck бувають у 10 і навіть більше разів швидшими, ніж ext3.

дві досить цікаві статті цього пошуку:

http://thunk.org/tytso/blog/2008/08/08/fast-ext4-fsck-times/ іhttp://thunk.org/tytso/blog/2009/02/26/fast-ext4-fsck-times-revisited/


-1

Чи є якась причина, чому ви не можете використовувати файлову систему, яка не примушує вас на перезавантажувати час fscks на основі часу чи монтажу?

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

у будь-якому випадку, XFS - одна з файлових систем журналу, яка не примушує fsck. варто подивитися.


інший варіант - використовувати Nexenta (ядро opensolaris, debian userland), що дасть вам ZFS. <A href=" nexenta.org/"> http://www.nexenta.org/</A >
Cas

3
Коли файлова система пошкоджується, незалежно від того, що вона є (extN, XFS, ZFS, що б там не було), чи не маєте ви часу та часу монтажу, їй потрібен fsck. Я хочу переконатися, що для пошкодження однієї пошкодженої файлової системи не потрібно занадто багато часу.
живіт

1
так, звичайно, fs потребує fsck, якщо він був пошкоджений. використання таких файлів, як XFS, не усуне їх, а також не потрібно намагатися або навіть хотіти. Я не сказав нічого, що могло б розумно трактуватися інакше. Моя думка полягала в тому, що форсувати fsck просто тому, що минуло X багато днів або Y багато монтив, оскільки останній fsck є непотрібним і дратівливим і, можливо, навіть "обмежує кар'єру", особливо якщо ваші користувачі або ваша компанія чекають, коли сервер прийде назад. ви можете усунути ці непотрібні fscks, і зробити це добре діло.
cas

Наскільки це добре (а може і не бути), воно не відповідає на поставлене питання.
жіноча
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.