Свежие комментарии

И когда узкое место - приемник, то ситуация та же:

device     r/s   w/s     kr/s     kw/s  ms/r  ms/w  ms/o  ms/t qlen  %b
aacd0      207     0  35263.6      0.0     3     0     0     3    0  43
aacd1      207     0  35263.2      0.0     3     0     0     3    0  42
aacd2      207     0  35334.8      0.0     3     0     0     3    0  42
aacd3      207     0  35317.2      0.0     4     0     0     4    0  44
aacd4      207     0  35310.8      0.0     3     0     0     3    3  41
aacd5      208     0  35465.6      0.0     5     0     0     5    0  54
aacd6      206     0  35074.0      0.0     3     0     0     3    0  41
aacd7      206     0  35073.6      0.0     3     0     0     3    0  40
 

Я вот подумал - в данном наблюдении основным критерием является производительность чтения. Если оттолкнуться от - "UPDATE: с большими файлами (их чтением) та же ерунда - нагрузка не равномерна по дискам, а плавает, на двух больше - на четырех меньше и так по кругу по дискам.", то возникает вопрос что быстрее читать одинаковый объём с 4 дисков непрерывно или с 6 с дырками? Даже интересно стало узнать результат.

На вскидку из vdev_raidz.c:
/*
* If all data stored spans all columns, there's a danger that parity
* will always be on the same device and, since parity isn't read
* during normal operation, that that device's I/O bandwidth won't be
* used effectively. We therefore switch the parity every 1MB.
*
* ... at least that was, ostensibly, the theory. As a practical
* matter unless we juggle the parity between all devices evenly, we
* won't see any benefit. Further, occasional writes that aren't a
* multiple of the LCM of the number of children and the minimum
* stripe width are sufficient to avoid pessimal behavior.
* Unfortunately, this decision created an implicit on-disk format
* requirement that we need to support for all eternity, but only
* for single-parity RAID-Z.
*
* If we intend to skip a sector in the zeroth column for padding
* we must make sure to note this swap. We will never intend to
* skip the first column since at least one data and one parity
* column must appear in each row.
*/

с массива, который делался без этих извращений - все хорошо, загрузка равномерная.

Поздравляю!
Надеюсь, Вы не скоро забросите это бесполезное занятие.

А вот пользы от него накопилось уже на все 20!
Спасибо, оставайтесь в кэфире :)

А почему не zfs send/receive кстати?

Я тут играюсь с zfs-on-linux, выглядит интересно, если взлетит -- буду думать, как переехать с lvm+md на zfs mirror (видимо тоже подегрейдить md, zpool attach /dev/вторая-половина, и после resilvering заменить так же первую, выдернув из под него lvm.

Не отвечая конкретно (потому что личный архив - это дело интимное) приведу один пример и пару соображений:

Пример:
Просто выход на ближайшую лужайку на часок-другой с фотоаппаратом ("выгулять объектив") - это кадров 200. То есть гигабайт 10-15, в зависимости от камеры. Более обдуманное упражнение "а давайте научимся стеки делать" - это наверное кадров 1000 (несколько десятков разных стеков) т.е. 50-80 гигов и еще минимум втрое результатов этих склеек.
И уж результаты склеек и исходники - имеет смысл похранить, чтобы когда появится новый софт - посравнивать.
Так и набегает, у меня еще мало.

Соображение1: все что выкачано из интернета для работы (и, тем более, прислано юзерами) - сохраняется. Потому что понадобится потом - и не найдешь. За этот год - уже ~полтерабайта равок, год еще не кончился.

Соображение2: все что хранится "в архивном архиве" - обязательно пропадет. Диск не прочтется, дисковода-лентовода не найдется, всякое бывает. Поэтому должна быть мастер-копия с контролем целостности и от нее расходится остальное.

P.S. И это я еще видео не снимаю.

Было бы что-то, что затрагивает широкий круг - я бы написал.

Ради .SR2 (не самый распространенный формат в наше время) - не стал.

Но на самом деле разница 1000-1002 маленькая
- исправлена бага с Sony .SR2 (много у вас таких файлов?)
- при первом запуске будет находиься фотошоп 2017 (но это вообще старых юзеров не касается)

А почему тут нет анонсов новых билдов?
Был 1000, забрал, поставил.
Случайно залетел на хомяк, а там уже 1002.

В полтора раза?

A7R-II я покупал в 2015-м (когда все эти флуктуации уже случились первый раз в конце 2014) - стоила $3300 по курсу на тот день. При штатовском ценнике $3200.

А сломалось что-то у них в конце 2015, даже вот до январского временного скачка уя.

Ну, теперь видимо попросту жадность победила - я недавно на всякие там ихи ILCE-6300 и прочее ценники смотрел - офигел просто.

И, заметим, Сони справлялись с российским ценообразованием и цены до ~2015г были вменяемыми.