Поддерживает ли UFS2 файлы больше 1Tb?
Да, поддерживает (интернеты в этом расходятся, было немножко нервно):
lexa@home-gw:~# ls -l /DATA/
total 3446778112
-rw-r--r-- 1 root wheel 877456780272 Nov 2 18:24 archive-books3
-rw-r--r-- 1 root wheel 1844203276336 Nov 3 01:49 archive-photoarc
-rw-r--r-- 1 root wheel 171793351432 Nov 2 19:47 archive-photoother
-rw-r--r-- 1 root wheel 635185397760 Nov 3 11:49 archive-raw-archive
Это уже второй 6-терабайтник заполняется, игра в 15, так ее растак:
- Cбэкапить текущий ZFS (6x4Tb, RAIDZ1)
- Собрать новый в деградированном виде (6xTB, RAIDZ2, два висят в воздухе)
- Накатить с бэкапа
- Восстановить четность массива
- Да, а потом четверки пойдут вместо терабайтников в другой ящик, а терабайтники - на дискетки.
И при этом - всегда иметь минимум 2 копии данных, хотя бы думать что имеешь (нет, есть еще копии, но далеко).
А слайды в папках стоят на полке и ничего этого не требуют. Но и второй (третьей, четвертой) копии нет.
P.S. Нет, собрать оба массива в одном ящике не могу, питания не хватит, покупать ради этого питальник как-то глупо.
Кроме того, на самом деле тот который 6x4, там один диск уже 6 (вместо вылетевшего летом) и пойдет в новый массив.
P.P.S. Узнал, что у df есть ключик -g
Comments
На 10.3-STABLE/amd64 и UFS2 с
На 10.3-STABLE/amd64 и UFS2 с дефолтными размерами блока/фрагмента 16K/2K можно даже более 128TB:
$ truncate -s $(echo "2^47+2^36+2^25+2^17+2^16-1" | bc) big
$ ls -l big; ls -lh big
-rw-r--r-- 1 eugen eugen 140806241583103 3 ноя 17:50 big
-rw-r--r-- 1 eugen eugen 128T 3 ноя 17:50 big
Теория под константами в формуле такая, (c) 2004,
Bruce Evans:
It is given by the same formula as for any ffs file system. The main limit
is that there are only 3 levels of triple indirection, so not many more than
N**3 logical blocks can be addressed, where N = <(illogical) block size> /
... The default block sizes of 16K/2K combined with ffs2's 64-bit lba's give N = 2048 and N**3 * = 16TB. The actual limit is a little larger (add terms of N**2 + N + C -- these are dominated by the N**3 term).
Ну вот интернеты расходятся в
Ну вот интернеты расходятся в этой цифре, например сановский (оракловый) UFS - размер файла до терабайта вроде.
А формулы я, да, не знал.
Тут вообще смешно.
С 1 стороны, что мешает "заархивировать" диск в стиле Win95?
С другой - много разных фс позволяют хранить "непрерывный" файл в много-много Мегабайт.
Как всегда, ограничивают надёжность хранения и скорость доступа (как минимум, чтения).
Забавно.
Чем более отказоустойчивый массив, тем больше геморроя!
Я, начитавшись, огород городить не стал...
... и тупо ограничился внешними_USB_HDD (3 штуки).
Понимаю, что Вам КРАЙНЕ важна скорость доступа. И это Ваша личная проблема. Если её отбросить (у других людей приорететы несколько иные), то всё вырождается-вырождается-ВЫРОЖДАЕТСЯ...
PS. Сам чуть не замутил zfs-массив, но лень помешала. А потом мне стало страшно. :-(
Ну просто вот когда счет уже
Ну просто вот когда счет уже идет на десятки терабайт (а у меня начался второй десяток - и я надеюсь проблему закрыть ну вот лет на пять) - с внешними МЕДЛЕННЫМИ дискетками очень уж все медленно.
Интимный вопрос:
А что на этих,условно, 15ТБ?
Видео, фотки свои и чужие, проги свои и чужие, сорцы...
Поделитесь, в каком соотношении это всё конкретно у Вас. ;-)
Вся эта инфа помещается на 15 дискет. Если учесть редко используемые данные, наверняка можно обойтись ~4 дискетами по 1 ТБ. А то и двумя...
Остальные дискеты (с менее актуальными данными) лежат рядом на полке и свои моточасы не жрут.
И резервные копии тоже делаются проще и быстрее
Да, 10Г-сеть такими дискетами не загрузить, даже если у них внутри RAID0. :-(
Не отвечая конкретно (потому
Не отвечая конкретно (потому что личный архив - это дело интимное) приведу один пример и пару соображений:
Пример:
Просто выход на ближайшую лужайку на часок-другой с фотоаппаратом ("выгулять объектив") - это кадров 200. То есть гигабайт 10-15, в зависимости от камеры. Более обдуманное упражнение "а давайте научимся стеки делать" - это наверное кадров 1000 (несколько десятков разных стеков) т.е. 50-80 гигов и еще минимум втрое результатов этих склеек.
И уж результаты склеек и исходники - имеет смысл похранить, чтобы когда появится новый софт - посравнивать.
Так и набегает, у меня еще мало.
Соображение1: все что выкачано из интернета для работы (и, тем более, прислано юзерами) - сохраняется. Потому что понадобится потом - и не найдешь. За этот год - уже ~полтерабайта равок, год еще не кончился.
Соображение2: все что хранится "в архивном архиве" - обязательно пропадет. Диск не прочтется, дисковода-лентовода не найдется, всякое бывает. Поэтому должна быть мастер-копия с контролем целостности и от нее расходится остальное.
P.S. И это я еще видео не снимаю.
Кстати, сырые данные тестов
Кстати, сырые данные тестов "шум в зависимости от выдержки" я не хранил -места мало.
Сейчас - пока место появилось - буду хранить.
Выгулять объектив...
Но ведь большинство кадров с таких гулянок не актуальны каждый день. Даже если не говорить о ежедневной необходимости всех 200 кадров годичной, например, давности.
То же и по склейкам: я, например, держу все *.CR2 на внешних ХДД, там же архивные результаты склейки, актуальные - на рабочем компе.
(У меня в компе всякой фигни ТераБайт 5, не меньше... и я чётко понимаю, что не менее 3ТБ я не трогал 2 года и более!)
"Соображение 1" опровергается банальным вопросом: А как Вы находите что-то в едином дисковом массиве? ;-)
С "Соображением 2" спорить труднее. :-( Но вот у меня и первые "архивные" (да и "как бы рабочие") диски все живы лет уже 10 как. Просто они крутятся полдня в год от силы, и практически все физически отключены и от питания.
В насилуемой Линуксами машинке без нареканий дышит винч на 250ГБ.
От полного форсмажора zfs Вас не спасёт, а наличие копий (хранимых географически отдельно) с мастер-копии делает периодическую возню с zfs-массивом эээ... увлечением. ИМХО. Причём с перчинкой! А ну как не взлетит?!
Остаётся только скорость доступа. Этот аргумент ничем не перебить.
>> А как Вы находите что-то в
>> А как Вы находите что-то в едином дисковом массиве
Что касается моих результатов труда - "я знаю что где лежит".
С архивом чужих равок сложнее, там общая свалка, да. Бывает минуть 5 приходится тратить.
"я знаю что где лежит"
Это не аргумент в пользу единого хранилища.
Я тоже знаю что на каком внешнем диске у меня лежит. И жена знает. :-)
"С архивом чужих равок сложнее"... Это вопрос организации хранения, но не вопрос преимущества Вашей "системы хранения" относительно моей. Однако мою обслуживать проще. ИМХО!
Я не критикую и не агитирую. Мне интересно, почему именно предпочтительнее идти более сложным и более затратным (как в плане железа, так и в плане "ежедневных затрат" на питание и обслуживание) путём.
Ну вот по моему опыту - то,
Ну вот по моему опыту - то, чего нет в немедленном доступе - на практике не существует.
Ваш опыт может отличаться.
Что есть "немедленный доступ"?
У каждого свои индивидуальные критерии.
Для меня воткнуть 2 провода + разгон блинов (= менее 20сек) и есть "немедленный доступ".
Т.к. актуальная инфа есть и локально, не вижу в этом проблемы: поиск "глазами", даже на локальных внутренних дисках, редко бывает на порядок короче. Разве что весь рабочий стол ярлыками залепить...
Немедленный доступ - это взял
Немедленный доступ - это взял и посмотрел.
Дошел до шкафа, нашел нужную дискету, воткнул (а еще при этом старую размонтировал) - не немедленный.
Ну и второе, на zfs мне доступна проверка целостности всего архива вообще без движений (и где-то за ночь она и произойдет и будет отчет). С дискетами - она будет происходить в разы медленнее (~100Mb/sec вместо 700) и требовать внимания на смену дискет.