Особенности использования большого hdd

Написал многобуков, стёр. Краткое содержание: делать то, что деформирует восприятие реальности в желаемую сторону (быстрее, дольше, надёжнее), не забывая о том, что любые нестандартные решения от большого ума мрут на порядок чаще.

Желания самостоятельно лезть в дебри и смотреть что как работает у меня нету, а потому я наверное просто буду юзать ext4 с noatime :)

Если кто предложит заведомо более быстрый вариант, то перейду на него.
Просто ранее у меня вся мультимедия была распихана по трем-четырем домашним компам. :)

У меня два винта, 1,5тб и 3тб, оба сигейт, на обоих ntfs. Полет нормальный уже в течение 3х и 2х лет соответственно. Насчет скорости никогда не запаривался, работает и работает.

ничего ценного там не будет.
чтобы большой диск работал быстрее и дольше?

Отключить журнал и своп.

Поговаривают, что на крупных файлах XFS идеальна.
KRoN73

gpt, фс по вкусу остальное несущественно

Она не то, чтобы идеальна, просто хороша, когда ничего удалять не надо (если надо — то fail). Другое дело, что у XFS единственный нормально работающий онлайновый дефраг на сегодня (e4defrag, порой, ведёт себя очень странно). Так что для торрент-файлопомойки с киношками, скажем, XFS прекрасна.

В остальном использую ext4. Но... И тут как-то не всё хорошо. Она на старых моих тестах под Gentoo была лидером, а недавно копировал под Ubuntu .opera в другое место того же раздела, так копирование шло со скоростью 4Мб/с (при скорости винта ~110Мб/с). Похоже, нужно как-то собраться и перетестировать в нынешних условиях.

нужно как-то собраться и перетестировать в нынешних условиях

Давайте сюда скрипты или методику тестирования, а мы сами.

Ну gpt это естественно, т.к у меня там один раздел на весь диск :)

ntfs очень сильно грузит процессор, а он на шаре старенький.
Да и кроме шары там ещё пара игровых серверов висит :)

Ну если как нибудь потестишь, то кастани меня.

Если серьёзный тест задумаю, то как новость результаты оформлю, наверное. Но вряд ли скоро, пока много куда более приоритетных дел висит. С другой стороны, я на приоритеты свои не часто смотрю, иногда всякой фигнёй внезапно занимаюсь :)

Нафига нтфс? О.о

1 - Обсуждалось. 2 - Нет. 3 - Обсуждалось неоднократно.

Поиск или google ... site:linux.or.ru

Потому что ВНЕЗАПНО я пользуюсь не только линуксом.

Да и лично мне без разницы, какая там фс. Чисто на глаз я эту мифическую разницу в скорости в 0,1 секунды не вижу, диск как диск.

Ну так я тоже временами под винду заскакиваю. Можно сделать ext3, влупить на оффтоп ext2fsd и всё будет прекрасно. По зиме сидел без линуха, но полдиска было по ext3, файлопомойка держалась прекрасно. Единственная причина почему у меня съёмный винт на нтфс в том, что просто некуда скинуть своё барахло чтобы форматнуть винт в ext3 и залить обратно. Но раз и так всё прекрасно умвр, то и не лезу. :)

У меня 2Tb, ext4, relatime.

Можно, но зачем, если и так работает?

а недавно копировал под Ubuntu .opera в другое место того же раздела, так копирование шло со скоростью 4Мб/с (при скорости винта ~110Мб/с).

Много мелких файлов, плюс копирование на тот же диск. В результате узким местом становится не пропускная способность, а IOPS'ы

1 - Нет ли каких тонкостей в современных ядрах чтобы большой диск работал быстрее и дольше?

Для 3 Тб наверняка используются большие 4k сектора. Следи чтобы блоки ФС были выровнены по секторам правильно. Проще всего - выравнивай всё по границам 1 МиБ и не парься.

2 - Нет ли сейчас проблем с парковкой головок и прочим?

Они были у WD зелёных серий, а не у Seagate

В принципе 0.0001% шанс, что оно упадет и убьет данные меня не пугает, т.к ничего ценного там не будет.

Зря. Время, которое ты потратишь на сбор этих файлов, в случае проблем будет очень жаль.

Кстати, если ты не собираешься забить все 3 Тб сразу, очень советую сделать LVM и часть диска оставить про запас. ext* прекрасно расширяются на лету, другие - в offline, но тоже расширяются. А если передумашь - всегда сможешь создать новый раздел с другой ФС и перенести на него данные

При записи / чтении больших объёмов на ntfs-3g процессор очень сильно грузится. ntfs имет смысл использовать, только если не обойтись без обмена с windows большими файлами

Много мелких файлов, плюс копирование на тот же диск.

Спасибо, кэп!

В результате узким местом становится не пропускная способность, а IOPS'ы

Вот только раньше такого эффекта не наблюдалось. Чтение мелочи в ext4 было очень шустрым, запись вообще не оказывала влияние, ибо кеш. А сейчас такое впечатление, что оно стало копировать напрямую, с диска на диск, забив на кеширование. Да и само чтение неоптимальное, без упреждения.

1 - Нет ли каких тонкостей в современных ядрах чтобы большой диск работал быстрее и дольше?

Нет.

2 - Нет ли сейчас проблем с парковкой головок и прочим?

Есть. Нужно устанавливать специальную приблуду (ataidle) для того, чтобы задавать SMART-параметры диска при старте системы.

3 - Какую файловую систему выбрать для моих целей чтобы работало шустро?

ZFS, конечно же, — у неё куча параметров для тюнинга под определённые задачи использования. Диск лучше весь целиком отдавать под ZFS без разметки на разделы, так как рекомендуется иметь по одному LUN'у на каждый физический носитель. А там уже можно думать о расширении пула, докупая винчестеры по мере нужности.

ataidle

шо эта, шо даёт? в репах нету... или оно на фрю?

Побуду кэпом ещё раз :)

Чтение мелочи в ext4 было очень шустрым, запись вообще не оказывала влияние, ибо кеш. А сейчас такое впечатление, что оно стало копировать напрямую, с диска на диск, забив на кеширование.

а) забит кэш ( или потребовалась память ) и приходится писать на диск
б) поменялся планировщик IO или его параметры ?
в) в фоне идёт другое интенсивное чтение?

Да и само чтение неоптимальное, без упреждения.

Если файлы сильно фрагментированы - это нормально
readahead настраивается через blockdev --setra <число секторов>

Можно ли более агрессвно кэшировать только inod'ы - не знаю :\

1 - чем партиция ближе к началу диска, тем быстрее - но это физика, а не Линукс
2 - лет 10 такого нет, от Линукса опять же не зависит
3 - XFS/ext4, у XFS есть defrag

Следи чтобы блоки ФС были выровнены по секторам правильно. Проще всего - выравнивай всё по границам 1 МиБ и не парься.

А как проверить как их по дефолту «выровнял» gparted?

Зря. Время, которое ты потратишь на сбор этих файлов, в случае проблем будет очень жаль.

Ну у меня через хитрые костыли скорость скачивания под 100 мегабит, а потому перекачать то что надо мне не сложно.
Т.к все что сколько нибудь ценное есть на удаленном дедике.

Кстати, если ты не собираешься забить все 3 Тб сразу ... А если передумашь - всегда сможешь создать новый раздел с другой ФС и перенести на него данные.

Вот это дельный совет, скорее всего так и сделаю.

А как проверить как их по дефолту «выровнял» gparted?

нужно при создании разделов сделать чтоб первый раздел начинался не от начала диска, а с отступом в 1 м

А как проверить как их по дефолту «выровнял» gparted?

fdisk -l -u /dev/sd*

смотри на размер сектора и Start

Наример, вот раздел выровненный по 1 МиБ границе ( 512 * 2048 = 1024^2 = 1M ):

Units = sectors of 1 * 512 = 512 bytes
[...]
/dev/sda1   *        2048      206847      102400   83  Linux

Вдогонку: если этот диск будет использоваться как системный, лучше выделить под загрузчик отдельный раздел, в начале диска.

ЗЫ. 3 Тб - это уже GPT, а не MBR. С ним не сталкивался.

Спасибо за инфу, проделаю у себя как освобожусь.

ATAidle is a utility to set the power management and performance
features of ATA hard drives.  This includes standby timeouts, power
(APM), write cache and acoustic (AAM) level settings, and it can show
details about the installed devices.

http://www.cran.org.uk/~brucec/software/

все тоже самое. Используем parted или gdisk. Выравнивание по границе 2048 или 8 секторов. В parted есть команда «align-check {min,opt} n» для проверки выровнености раздела, только для gpt она не совсем ожидаемо реализовано, но покопавшись в исходниках, выясняется, что это не баг - это фича.

а в чём отличие от hdparm?

ntfs очень сильно грузит процессор, а он на шаре старенький.

Недавно копировал, загрузки на процессор практически небыло, перед этим (больше полгода назад) загружало ядро. Может уже починили?

Копировал один большой файл или много мелких?

ST3000DM001

это которые тарахтят головкой каждые полминуты?

Копировал один большой файл или много мелких?

И такие, и такие.

У меня два винта, 1,5тб и 3тб, оба сигейт, на обоих ntfs

Ы? На кой фиг ntfs?

Если бы ты слышал агрегат где это все стоит, то понял бы почему мне все равно :)
У меня нет никаких шансов услышать как оно шуршит.

А какой у тебя процессор?

core i5 430m, gentoo ~amd64.

1. Он и так быстро и долго работает — главное не ронять включенный.
2. У полторашек «гринов» есть. У остальных вроде уже нет.
3. Смотря что там хранить (большие файлы или мелочь). Лично мне нравится reiserfs.

А зачем тебе высокая скорость, если там только файлы? Чтобы музыка быстрее слушалась?

Толсто

Ключевой момент: core i5.
Это реально очень мощный процессор.

У меня на файлопомойке протухший Core2Duo, и на нем нагрузка от ntfs будет значительна.

У тебя видимо дома 100 мегабит локалка? :)

проц то мобильный. Сегодня вечером потещу еще.

Мобильный он или нет, но мой (тоже мобильный) i3 значительно быстрее в играх и тоже ntfs ворочает неплохо.
А вот десктопный Core2Duo которому уже лет 5 заметно ему сливает.