Змусьте Linux записувати в мережеву файлову систему одночасно з читаннями на локальному диску

Підсумок

Як можна налаштувати Linux одночасно і на читання з локального диска / файлової системи, і на запис на загальну мережу, на відміну від читання, поки дані не надходять через мережу, а потім надсилати ці дані по мережі, коли локальний диск є простоювати?

Набагато швидше читати і писати одночасно, замість того, щоб виконувати лише одну операцію, а потім іншу по черзі.

Деталі

Я переміщую велику кількість даних з локальних дисків на машині Linux до пристрою NAS.

Я rsyncв основному використовую для копіювання /srv/dataв /mnt/nasце CIFS-кріплення.

Це почалося добре, читаючи зі швидкістю 100 Мб / сек і записуючи в NAS зі швидкістю 100 МБ / сек (ліміт гігабітної мережі), одночасно читання та запис відбувається одночасно.

Однак зараз, через кілька годин, я виявляю, що він читає з локального диска, потім зупиняє прочитане, поки він пише в NAS, тоді, коли більше даних для запису в NAS немає, він продовжує читати з диска знову. Мережа в режимі очікування, коли диск читається, а диск в режимі очікування, коли мережа використовується.

Потрібно сказати, що читання 200MB, а потім запис 200MB займає набагато більше часу, ніж читання та запис цих 200MB одночасно.

Як я можу налаштувати ядро ​​таким чином, щоб воно дотримувалося попередньої поведінки читання і запису одночасно, а не чергування читання і запису, виконуючи лише одну операцію за один раз?

Деякі зауваження: Коли локальний диск читає зі швидкістю 100 Мб / сек, все, здається, відбувається паралельно просто чудово, але як тільки диск сповільнюється (здається, чомусь зараз йде лише 20 МБ / сек), саме тоді читається / записується переключення, здається, відбувається.

Я також можу запускати syncвручну кожні кілька секунд, щоб зробити записи, що відбуваються паралельно з читанням (хоча, очевидно, зі зниженою швидкістю), однак введення циклу, щоб він syncпрацював whileкожні п’ять секунд, не здається правильним рішенням ...

Здається, ядро ​​кешує близько 1 ГБ даних, а потім виписує їх по мережі якомога швидше - що нормально - я просто не розумію, чому повільний диск потрібно перестати читати, поки дані надсилаються через мережа.

Після ще одного розслідування, схоже, ця проблема не стосується ядра та більше про те, як rsyncі CIFS взаємодіють.

Наскільки я можу зрозуміти, що відбувається, це те, що після rsyncзакриття файлу призначення CIFS (і, мабуть, будь-яка мережна файлова система) гарантує, що файл повністю очищений та записаний на віддалений диск до closeповернення syscall. Це гарантує будь-яку програму, що після завершення операції закриття файл буде повністю збережено, і немає ніякого ризику виникнення додаткових помилок, які можуть призвести до втрати даних.

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

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

Вирішення проблеми полягає у встановленні спільного доступу до CIFS із можливістю cache=noneвимкнення цієї функції та змушує усі введення-виведення переходити безпосередньо до сервера. Це усуває проблему і дозволяє паралельно виконувати читання та запис, проте недолік цього рішення полягає в тому, що продуктивність дещо нижча. У моєму випадку швидкість передачі мережі падає з 110 МБ / сек до 80 МБ / сек.

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

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

EDIT: Я підтвердив, що cache=noneбезумовно допомагає при передачі безлічі невеликих файлів (приносить їх від 10 Мб / сек до 80 МБ / сек), але при передачі великих файлів (1 ГБ +) cache=noneзнижує передачу з 110 МБ / сек вниз до тих же 80 МБ / сек. Це говорить про те, що повільна передача з багатьох невеликих файлів менше стосується шуканого вихідного диска, а більше про те, що стільки залишків кешу йде з усіх невеликих файлів.