Как достигается надежность с помощью SCSI и SAN?
find your_folder -type f -name "*_fa_a*" | while read filename; do echo mv "${filename}" destination_folder; done
эта команда find находит файл и перемещается в папку назначения.
Я добавил команду echo, чтобы вы могли проверить результаты перед перемещением. как только вы будете довольны выводом команды echo, удалите команду mv.
Это может быть ошибка ServerFault.
Но вы совершенно правы. Fibre Channel не имеет тех же механизмов защиты, что и TCP. В этом отношении это больше похоже на UDP (хотя это немного слабая аналогия), и по многим из тех же причин - для некоторых приложений TCP является плохим решением из-за этих механизмов надежности - ваш поток может `` остановиться '' для повторной передачи, и это вредит приложению, работающему почти в реальном времени, больше, чем отброшенный пакет. Задержка ввода-вывода хранилища вы начинаете «болеть», когда вы превышаете примерно 20 мсек, а для TCP этого времени на самом деле недостаточно.
Что происходит с FCP, так это то, что драйвер SCSI на конечной точке обеспечивает надежность, потому что как часть этого он также может выполнять балансировку нагрузки. Как правило, вы не будете подключать одно волокно, а вместо этого получите два HBA с двумя независимыми путями к хранилищу.
Таким образом, ваш драйвер маршрутизирует пакеты так, как ему нравится (некоторые из них умнее других - в наши дни большинство из них используют многопутевое соединение, но некоторые делают довольно умный адаптивный многопутевый переход) и отслеживает, какие операции ввода-вывода были подтверждены, а какие нет. ОС может ставить в очередь ввод-вывод, где это необходимо, или ... ну, нет, если считает, что это плохая идея. Фактически, он в любом случае делает это как часть обычных механизмов кэширования файловой системы.
Вот почему, например, open имеет параметр O_DIRECT :
O_DIRECT (начиная с Linux 2.4.10) Попытайтесь минимизировать эффекты кеширования от Ввод / вывод в этот файл и из него. Как правило, это снижает производительность, но полезно в особых ситуациях, например, когда приложения выполняют собственное кэширование.Файловый ввод-вывод выполняется непосредственно пользователю / от пользователя - пространственные буферы. Флаг O_DIRECT сам по себе пытается передавать данные синхронно, но не дает гарантий флага O_SYNC, что данные и необходимые метаданные передаются. Чтобы гарантировать синхронный ввод-вывод, O_SYNC должен использоваться в дополнение к O_DIRECT. См. ПРИМЕЧАНИЯ ниже для дальнейшего обсуждения.
Я нашел неофициальную статью, в которой проводилось такое же сравнение, что соответствует моему приблизительному впечатлению. В статье также показано многопутевое соединение, чтобы выжить при отказе коммутатора FC или одного из кабелей в большой сети SAN, как упоминает @Sobrique.
SCSI не любит отбрасывать команды. Это неправильное представление о том, что SCSI не может терпеть потерянную команду. Может, просто нужно много времени на восстановление (условно говоря). Я видел множество ошибок SCSI, и они замедляют работу системы до ползания. Так что лучше не терять никаких команд SCSI.
https://datacenteroverlords.com/2011/09/14/fibre-channel-and-ethernet-the-odd-couple/
Похоже, что FCP официально не гарантирует доставку , но ... Если вы читаете статью в Википедии, FibreChannel указывает определенную частоту битовых ошибок (приемлемую / ожидаемую). TCP разработан для работы по ссылкам, которые гораздо меньше заботятся о пакетах, чем FibreChannel.
FibreChannel также включает управление потоком, чтобы избежать потери пакетов из-за перегрузки / переполнения буферов. IP этого не делает (и не ожидает, что базовые сети будут делать это каким-либо образом).
Например, у Google есть эта классная статья , в которой они измеряли уровень потерь TCP-пакетов в среднем от 1% до 20% или даже выше . (Они выступают за то, чтобы интернет-провайдеры использовали технологию, которая приводит к потерям 1% (формирование), а не 20% + потерям (контроль). Эти технологии обычно позволяют IP-сетям решать проблему перегрузки).
Я полагаю, что большинство реализаций SCSI повторяют неудачные команды. Я не знаю, насколько он стандартизирован - я думаю, что его можно настраивать разными способами. Технически это также не гарантирует доставку, так же как вы можете ожидать, что TCP в конечном итоге истечет (TCP откажется и закроет соединение).