Как-то давно ваял прогу на wxWidgets, нарезающую >4 ГБ файлы, так там тоже столкнулся с тем, что счётчик записанных байтов начинался с нуля после то ли 4 ГБ (unsigned int), то ли 2ГБ (signed int), и под Windows, и под Linux (собирал под 32 бит).
Про 32бит Линукс-системы рассказано слишком много былин.
И сегодня это не проблема ядра.
Умение работать с большими файлами свыше 4GB, иногда это проблема ядра, иногда нет.
Ядро умеет работать с файлами свыше 4GB в ext4fs на 32 бит системах:
# uname -rm
4.4.94-std-pae-alt0.M80P.1.1 i686
# time -f %E dd if=/dev/zero of=/root/image.udf bs=1000k count=4589
4589+0 записей получено
4589+0 записей отправлено
4699136000 байт (4,7 GB, 4,4 GiB) скопирован, 50,983 s, 92,2 MB/s
0:50.98
# mkudffs --lvid=HD-Video --media-type=dvd -r 0x0150 /root/image.udf
# rhash --gost /root/image.udf
49e465d1af45ff5512296d8e8140b84cca3d6e67fd24b450c8a1828a6c328daa /root/image.udf
# rhash --md5 /root/image.udf
898e284a07d579ad04a648ef77f6798d /root/image.udf
Но когда-то не умело.
Ситуация складывалась так:
Сначала ядро умело записывать файлы свыше 4GB в udffs. Но начиная с ядра 2.6.27, эту возможность ядерщики благополучно разломали. Затем, начиная с ядра 3.10.32 снова научили.
И записывать файлы свыше 4GB в udffs на 32 бит системах, ядро умеет по сей день:
# time -f %E dd if=/dev/zero of=/root/iso.iso bs=1000k count=4299
4299+0 записей получено
4299+0 записей отправлено
4402176000 байт (4,4 GB, 4,1 GiB) скопирован, 48,8246 s, 90,2 MB/s
0:48.82
# mount /root/image.udf /mnt/disk -o loop
mount: /dev/loop0 is write-protected, mounting read-only
# mount -o remount,rw /mnt/disk/
# mount|grep udf
/root/image.udf on /mnt/disk type udf (rw,relatime,utf8)
# cp /root/iso.iso /mnt/disk/
# ls -l /mnt/disk/
итого 4299000
-rw-r--r-- 1 root root 4402176000 окт 28 16:00 iso.iso
drwxr-xr-x 2 root root 40 окт 28 15:50 lost+found
Поэтому если что-то не работает с файлами свыше 2-ух или 4GB, смотреть нужно в софт и ни Линус, ни ядро здесь ни при чём.