Интересный фикс в ядре 3.14.20

Ты часто работаешь с дисками >=4Tb? Тем более на 32-битных системах.

как это до сих пор это не замечали

32 бит актуально для случаев, когда памяти мало и её надо экономить. Файлсторадж к таким не относится. Ошибка в редкоиспользуемой конфигурации может жить годами.

а что у нас в небольших NAS-ах ? Там 4Гб рамы не часто встретишь даже с корзиной на 8-10 дисков

Там и диски больше 4 Тб особо не встретишь.

Если эта ошибка не проявляется на md & dm девайсах, то тогда понятно почему до сих пор не нашли.

Там же ясно написано, что диски. Не файловые системы, не блочные устройства. Диски больше 4 Тб с сектором 512 байт. Такие вроде вообще в потребительском секторе не встречаются.

#решето

Диски больше 4 Тб с сектором 512 байт. Такие вроде вообще в потребительском секторе не встречаются.

Уже встречаются.

Где написано «не блочные устройства» ?

Смущает фраза

This patch has been verified to fix the infinite loop problem on 3.17-rc5 kernel using a 4TB disk image mounted using "-o loop".

loop - это блочное устройство (как и dm/md) и в примере оно лежало через границу 4Тб

и

Any code that uses __getblk() (and thus bread(), breadahead(), sb_bread(), sb_breadahead(), sb_getblk())

функции которые используются при работе практически любой фс для блочных устройств.

А диск >4Т легко изобразит аппаратный рейд-контроллер или iscsi?

Так что IMHO есть повод задуматься.

Там 4K.

А, тогда да.

Там 4K.

Они там внутри, наружу торчит 512 и упоминание, что внутре всё чуть хитрее.

loop - это блочное устройство (как и dm/md) и в примере оно лежало через границу 4Тб

Довольно давно использую массив больше 4Тб на i386, но пока, слава Патрегу, никаких проблем не заметил. Интересно, в каких ситуациях оно проявляется.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/head/head.c?rev=1.18&amp...

у БСДшников всё ещё интереснее