Файлова система Linux з входами, закритими на диску

Я хотів би зробити ls -laR /media/myfsна Linux якомога швидше. У мене буде 1 мільйон файлів у файловій системі, 2 ТБ загального розміру файлів та деякі каталоги, що містять цілих 10000 файлів. Яку файлову систему я повинен використовувати та як її налаштувати?

Наскільки я розумію, причина, чому ls -laRце повільно, тому що вона має stat(2)кожний inode (тобто 1 мільйон stat(2)с), а оскільки inode розподіляються випадковим чином на диску, кожен stat(2)потребує одного пошуку диска.

Ось декілька рішень, які я мав на увазі, жодним із яких я не задоволений:

• Створіть файлову систему на SSD, оскільки операції пошуку на SSD швидко проходять. Це не буде працювати, тому що 2 ТБ SSD не існує, або це надмірно дорого.

• Створіть файлову систему, яка охоплює два блокові пристрої: SSD та диск; диск містить файлові дані, а SSD містить всі метадані (включаючи записи каталогів, inode та розширені атрибути POSIX). Чи існує файлова система, яка підтримує це? Чи пережив би це крах системи (відключення електроенергії)?

• Використовуйте find /media/myfsзамість ext2, ext3 або ext4, ls -laR /media/myfsтому що перший може перевага d_typeполя (див. На getdents(2)сторінці man), тому він не повинен стати статистичним. На жаль, це не відповідає моїм вимогам, оскільки мені також потрібні всі розміри файлів, які find /media/myfsне друкуються.

• Використовуйте файлову систему, таку як VFAT, яка зберігає входи у записах каталогу. Я хотів би цього, але VFAT для мене недостатньо надійний і гнучкий, і я не знаю жодної іншої файлової системи, яка б це робила. Чи ти? Звичайно, зберігання inode у записах каталогу не працюватиме для файлів із кількістю посилань більше 1, але це не проблема, оскільки у моєму використанні є лише кілька десятків таких файлів.

• Відрегулюйте деякі параметри приблизно /procабо sysctlтак, щоб узори заблоковані в системній пам'яті назавжди. Це не прискорить перше ls -laR /media/myfs, але зробить усі наступні виклики дивовижно швидкими. Як я можу це зробити? Мені ця ідея не подобається, тому що вона не прискорює першу виклик, яка наразі займає 30 хвилин. Також я хотів би зафіксувати розширені атрибути POSIX у пам'яті. Що мені робити для цього?

• Використовуйте файлову систему, яка має онлайн-інструмент дефрагментації, який може бути доручений перенести входи до початку блокового пристрою. Після того, як переміщення буде зроблено, я можу запустити, dd if=/dev/sdb of=/dev/null bs=1M count=256щоб отримати початок блокового пристрою, що піднімається до кешу пам’яті ядра, не шукаючи, і тоді stat(2)операції будуть швидкими, оскільки вони читаються з кеша. Чи є спосіб заблокувати ці входи та / або блоки в пам'яті, коли їх прочитали? Яка файлова система має такий інструмент дефрагментації?

Я продам вам свою відповідь на ваше запитання щодо вашої відповіді на мою: Які ручки потрібно встановити в / proc або / sys, щоб зберегти всі вставки в пам'яті?

Тепер для моєї відповіді на ваше запитання:

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

NetApp виконує завдання блискуче; все інше, що я спробував поки що, не робить.

Досліджуючи це, я знайшов кілька файлових систем, які відокремлюють метадані від даних, але всі вони мають деякі недоліки:

• dualfs: Є кілька виправлень для 2.4.19, але не багато іншого.
• luster: ls -l - найгірший сценарій, оскільки всі метадані, крім розміру файлу, зберігаються на сервері метаданих.
• QFS для Solaris, StorNext / Xsan: Невідомий для великої продуктивності метаданих без значних інвестицій.

Тож це не допоможе (якщо ви не зможете відродити подвійні елементи).

Найкраща відповідь у вашому випадку - максимально збільшити кількість шпинделя. Найпотворніший, але найдешевший і практичний спосіб зробити це - отримати корпоративну карту JBOD (або два) та карту з волоконного каналу Ebay, яким вже кілька років. Якщо ви виглядаєте важко, ви повинні мати можливість утримувати свої витрати менше 500 доларів США. Пошукові терміни "146gb" і "73gb" будуть дуже корисними. Ви повинні бути в змозі переконати продавця укласти угоду про щось подібне, оскільки у них є маса їх, що сидять навколо, і навряд чи є зацікавлені покупці:

http://cgi.ebay.ca/StorageTek-Fibre-Channel-2TB-14-Bay-HDD-Array-JBOD-NAS-/120654381562?pt=UK_Computing_Networking_SM&hash=item1c178fc1fa#ht_2805wt_1056

Налаштуйте смугу RAID-0 на всіх дисках. Створіть резервну копію даних релігійно, тому що один або два накопичувачі неминуче вийдуть з ладу. Використовуйте tar для резервного копіювання замість cp або rsync, щоб отримуючий один диск не повинен мати справу з мільйонами вкладень.

Це єдиний найдешевший спосіб, який я знайшов (у будь-який конкретний історичний момент, так чи інакше) для збільшення IOP для файлових систем у діапазоні 2-4 ТБ.

Сподіваюся, що це допомагає - або принаймні цікаво!

диск містить файлові дані, а SSD містить всі метадані ... Чи є файлова система, яка підтримує це?

btrfs певною мірою підтримує це, btrfs Wiki . Можна вказати raid1 для метаданих (і raid0 для даних - більшість даних виявиться на великому жорсткому диску), щоб SSD завжди мав копію метаданих для читання (я не маю уявлення про те, наскільки розумні btrfs будуть у виборі джерело для читання метаданих). Я не бачив жодних орієнтирів для такого налаштування.

На жаль, жодної відповіді, хоча я відповів Google за відповідь протягом останніх півгодини.

Створіть файлову систему, яка охоплює два блокові пристрої: SSD та диск; диск містить файлові дані, а SSD містить всі метадані (включаючи записи каталогів, inode та розширені атрибути POSIX). Чи існує файлова система, яка підтримує це? Чи пережив би це крах системи (відключення електроенергії)?

Саме те, що я теж хотів би.

Для посилань див. Цю пастину, оскільки мені не дозволяється публікувати більше ніж одне посилання ...

http://www.notehub.org/2014/10/2/external-metadata-more-information

Тут обговорюється підтримка кількох пристроїв від btrfs:

Btrfs: Робота з декількома пристроями, автор Джонатан Корбет, 30 грудня 2013 р. (LWN), [посилання] [1]

Але хоча ви можете відобразити метадані (-m raid1) на SSD, ви змушені також використовувати SSD для зберігання даних (-d raid0), принаймні частково.

Хороша новина полягає в тому, що робиться робота:

Виділені метадані: Ян Шмідт та Арн Янсен (ще не в ядрі). Ми можемо дуже легко розділити дані та метадані IO. Метадані, як правило, домінують у пошуках, і для багатьох застосувань має сенс розміщувати метадані на більш швидких SSD. [посилання] [2]

Якщо ви готові використовувати фірмову загальну паралельну файлову систему (GPFS) IBM, то це вже можливо, здається. Читайте "Як перемістити всі метадані файлової системи GPFS на SSD": [посилання] [3]

Я просто використовую ext4 і переконуюсь, що у вас встановлено dir_index. Ви можете перевірити цей прапор, виконавши цей:

dumpe2fs /dev/drivepartition | grep "Filesystem features:"

Найбільша проблема, з якою ви зіткнетеся, - це лише кількість файлів у цілому у файловій системі. Будь-яка операція, виконана у файловій системі, повинна переглянути кожен файл. Це стосується будь-якої файлової системи. 10 000 файлів у каталозі може здатися дуже багато, але я вважаю, що файлові системи не надто повільні, поки ви не отримаєте 40 000 файлів і більше, і це справді старіший симптом файлових систем на зразок ext2.

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