ZSTD sounds like a general push towrds new file system.
You should branch out and relabel as "Reiser5"
Remove all lzo, roll up sleeves and start hacking out all dead code ?
What say you?
How Refreshing
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A new plugin increments minor number of SFRN. A new format plugin increments
major number. A principal number (currently 4) gets incremented if there are
changes in master super-block. So I would suggest to release 4.0.2 with ZSTD
support. Reiser5 is for logical/networking volumes (approximately after NY).
We can not discontinue LZO support: what people will say? Everything should
be backward compatible..
Thanks,
Edward.
Last edit: Edward Shishkin 2017-09-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Reiser4 works seemlessly out of box well. No interaction or adjustment needed.
Use default ZSTD @ 4.0.2 / format switch back to LZO.
Only ZFS / HammerFS to compete on global level!
I appreciate feedback.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
May I ask you to port your stuff for linux-4.14? Can we align it to the common interface described in the header file (include/linux/zstd.h) to not poke around zstd internals? Reiser4 port for linux-4.14 can be found in https://github.com/edward6/reiser4. Thank you in advance.
Edward.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When i test ZSTD and LZ4 in R4 i got lower speed on lot of small files (unpack Linux kernel source tree for example). May be on faster CPU (i have Core i3 M330 on my notebook), or different hardware we got different results.
ZSTD and LZ4 have a lot of optimizations related to use of the stack. Because we can't use heap in kernel code (i'm right?), we got lower speed with heap.
Even on official Github page zstd didn't win from lzo. ZSTD win from gzip.
P.S. Sorry for the clumsy English.
Last edit: BratSinot 2017-10-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, you are right: kernel's stack is restricted. However kmalloc(size) and friends are rather fast (especially if @size is a compile-time constant), so I don't think it leads to visible performance drop.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In fact, in the 4.14 kernel ZSTD included. Squashfs and Btrfs did support ZSTD.
With this patch, the kernel builds well. But at this moment I can't check works it or no.
Часом не в местах выделения / освобождения памяти или преобразования типов? Да и момент с ZSTD_initCCtx() / ZSTD_initDCtx() я не до конца понял, т.е. что они вообще делают и почему возвращают указатель. В оригинальном коде ZSTD два варианта: ZSTD_createCCtx() со стандартными malloc() / free() и ZSTD_createCCtx_advanced() (где можно реализовать свои аллокаторы).
И кстати говоря, что в Btrfs, что в SquashFS сейчас используют потоковые (stream) варианты ZSTD. В ранних патчах в SquashFS предлагался вариант примерно как у меня. Даже точнее не в ранних патчах, а в патчах от других разработчиков. Потом уже Крис Масон сделал пулл-реквест от лица Facebook (в стенах которой так-же трудится разработчик ZSTD / LZ4) в оффициальную ветку ядра с реализацией ZSTD в .SquashFS и Btrfs.
Last edit: BratSinot 2017-11-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Хм... странно, только что проверил на своей живой системе никаких проблем. Пробовал из /dev/zero, /dev/urandom и исходный код ядра. Естественно после каждой операции делал sync / umount.
Правда делал я все это в файле, который находился в tmpfs.
Если поможет, то приложу конфиг ядра и результат lshw (полезная утилита для сбора детальной информации о железе). Reiser4 собирал в ядро, ибо когда собирал в виде модуля, то при линковке модуля вылезала какая-то ошибка связанная с find_get_pages_range().
Хм, а сегодня всё работает... В пятницу точно помню: ядро флудило сообщениями, что не может выделить память. Бывает, вобщем... :) Эту недельку погоняю тесты. Если всё нормально будет, релизнем 4.0.2 в эти выходные...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ну как вариант сделать немного велосипедную debug-версию, т.е. в zstd1_alloc(), в местах где просто возвращается -ENOMEM, добавить дополнительный warning(), ибо там память может 3 раза неправильно выделиться, а так хоть будет понятно в каком месте проблемы.
Last edit: BratSinot 2017-11-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
И, кстати говоря, имеется смысл сменить 3-й уровень сжатия на 1-й. на оффициальной странице в тестах используется именно он. Т.е. он будет сжимать лучше и быстрей gzip, а в некоторых случаях возможно и lzo обгонит (как мне кажется на 1-м уровне он будет актуален на не быстрых HDD).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ну, первый так первый. Ещё один организационный момент. Если у вас есть страница на гитхабе, то вы можете специальным образом приготовить и послать мне патч, так, что соответствующий коммит в репозитории reiser4 будет на неё указывать. Я могу послать инструкции как это сделать.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Да есть: https://github.com/BratSinot , почта в профиле указана моя, инструкции бы не помешали, а то я git'ом дальше pull / add / push и не пользовался.
Так а что за опечатки? Я бы сразу и исправил при подготовке патча.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
А можно в кратце в чем проблема? Я так понял, что в ядре что-то опять наколдовали с подсистемой памяти?
P.S. А есть ли разница межу SLUB / SLOB и т.д. в данном случае?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Там у них произошла "ломка неписанных правил", на которые закладывался reiser4. Раньше запрос с флагом GFP_KERNEL на выделение куска памяти не больше некоторого фиксированного размера никогда не возвращал ошибку. Теперь (через 15 лет), это отменили. Что у них там сейчас и как - я пока не разбирался, хотя это очень важно. В reiser4 есть пара мест, где ошибки аллокатора не могут быть обработаны. Одно из них в плагине (cryptcompress), который поддерживает сжатие. Ошибка возвращаемая методом ->alloc() of compression transform plugin сейчас обрабатывается - мы просто вставляем несжатые данные представленные одним буфером. А вот обрабатывать ошибку возвращаемую alloc_tfm_stream()(когда хотим 64К буфер, чтобы слить туда страницы перед компрессией) мы пока не можем. Для этого надо научиться вставлять в дерево несжатые данные, представленные несколькими неслитыми грязными страницами. Но это не так просто (я сам за это как-нибудь возьмусь).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Reiser5 is for logical/networking volumes (approximately after NY).
So, someone work on Reiser4? In your interview (in 2010), you mentioned that there is only enough time to adaptive code for new versions of the kernel, but there is not enough time to develop the file system itself. So, something change? Can we hope for the future development of Reiser4?
Last edit: BratSinot 2017-11-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ну раз такое дело, то думаю на следующих выходных попробовать gzip / lzo / zstd.
Из тестов, собираюсь потестить линейную запись пустого файла (из /dev/zero), линейную запись несжимаемого файла (из /dev/urandom сделаю файл на tmpfs, и из tmpfs уже скопирую на раздел) и распаковку исходного кода ядра (будет tar архив на tmpfs).
С первым уровнем сжатия не пробовал, но он должен быть лучше gzip.
ZSTD sounds like a general push towrds new file system.
You should branch out and relabel as "Reiser5"
Remove all lzo, roll up sleeves and start hacking out all dead code ?
What say you?
How Refreshing
Hello. Everything is protocoled ;)
https://reiser4.wiki.kernel.org/index.php/Reiser4_development_model
A new plugin increments minor number of SFRN. A new format plugin increments
major number. A principal number (currently 4) gets incremented if there are
changes in master super-block. So I would suggest to release 4.0.2 with ZSTD
support. Reiser5 is for logical/networking volumes (approximately after NY).
We can not discontinue LZO support: what people will say? Everything should
be backward compatible..
Thanks,
Edward.
Last edit: Edward Shishkin 2017-09-28
Reiser4 works seemlessly out of box well. No interaction or adjustment needed.
Use default ZSTD @ 4.0.2 / format switch back to LZO.
Only ZFS / HammerFS to compete on global level!
I appreciate feedback.
May I ask you to port your stuff for linux-4.14? Can we align it to the common interface described in the header file (include/linux/zstd.h) to not poke around zstd internals? Reiser4 port for linux-4.14 can be found in https://github.com/edward6/reiser4. Thank you in advance.
Edward.
When i test ZSTD and LZ4 in R4 i got lower speed on lot of small files (unpack Linux kernel source tree for example). May be on faster CPU (i have Core i3 M330 on my notebook), or different hardware we got different results.
ZSTD and LZ4 have a lot of optimizations related to use of the stack. Because we can't use heap in kernel code (i'm right?), we got lower speed with heap.
Even on official Github page zstd didn't win from lzo. ZSTD win from gzip.
P.S. Sorry for the clumsy English.
Last edit: BratSinot 2017-10-23
Yes, you are right: kernel's stack is restricted. However kmalloc(size) and friends are rather fast (especially if @size is a compile-time constant), so I don't think it leads to visible performance drop.
In fact, in the 4.14 kernel ZSTD included. Squashfs and Btrfs did support ZSTD.
With this patch, the kernel builds well. But at this moment I can't check works it or no.
Last edit: BratSinot 2017-10-30
Thanks!
Ну, вроде всё работает, не считая пары опечаток. Сделаем стабильный релиз SFRN 4.0.2 для Linux-4.14
Часом не в местах выделения / освобождения памяти или преобразования типов? Да и момент с ZSTD_initCCtx() / ZSTD_initDCtx() я не до конца понял, т.е. что они вообще делают и почему возвращают указатель. В оригинальном коде ZSTD два варианта: ZSTD_createCCtx() со стандартными malloc() / free() и ZSTD_createCCtx_advanced() (где можно реализовать свои аллокаторы).
И кстати говоря, что в Btrfs, что в SquashFS сейчас используют потоковые (stream) варианты ZSTD. В ранних патчах в SquashFS предлагался вариант примерно как у меня. Даже точнее не в ранних патчах, а в патчах от других разработчиков. Потом уже Крис Масон сделал пулл-реквест от лица Facebook (в стенах которой так-же трудится разработчик ZSTD / LZ4) в оффициальную ветку ядра с реализацией ZSTD в .SquashFS и Btrfs.
Last edit: BratSinot 2017-11-10
Нет, не там.
Попробовал потом на десктопе - аллокатор память почему-то не выделяет...
На виртуальной машине всё работало. Пока не разбирался...
Хм... странно, только что проверил на своей живой системе никаких проблем. Пробовал из /dev/zero, /dev/urandom и исходный код ядра. Естественно после каждой операции делал sync / umount.
Правда делал я все это в файле, который находился в tmpfs.
Если поможет, то приложу конфиг ядра и результат lshw (полезная утилита для сбора детальной информации о железе). Reiser4 собирал в ядро, ибо когда собирал в виде модуля, то при линковке модуля вылезала какая-то ошибка связанная с find_get_pages_range().
Last edit: BratSinot 2017-11-11
Хм, а сегодня всё работает... В пятницу точно помню: ядро флудило сообщениями, что не может выделить память. Бывает, вобщем... :) Эту недельку погоняю тесты. Если всё нормально будет, релизнем 4.0.2 в эти выходные...
Ну как вариант сделать немного велосипедную debug-версию, т.е. в zstd1_alloc(), в местах где просто возвращается -ENOMEM, добавить дополнительный warning(), ибо там память может 3 раза неправильно выделиться, а так хоть будет понятно в каком месте проблемы.
Last edit: BratSinot 2017-11-14
И, кстати говоря, имеется смысл сменить 3-й уровень сжатия на 1-й. на оффициальной странице в тестах используется именно он. Т.е. он будет сжимать лучше и быстрей gzip, а в некоторых случаях возможно и lzo обгонит (как мне кажется на 1-м уровне он будет актуален на не быстрых HDD).
Ну, первый так первый. Ещё один организационный момент. Если у вас есть страница на гитхабе, то вы можете специальным образом приготовить и послать мне патч, так, что соответствующий коммит в репозитории reiser4 будет на неё указывать. Я могу послать инструкции как это сделать.
Да есть: https://github.com/BratSinot , почта в профиле указана моя, инструкции бы не помешали, а то я git'ом дальше pull / add / push и не пользовался.
Так а что за опечатки? Я бы сразу и исправил при подготовке патча.
Профиля достаточно. Я сам всё сделаю, так быстрее будет. Вас попрошу только переделать патч на первый уровень компрессии.
Вот что у меня было:
https://marc.info/?l=reiserfs-devel&m=151074241219505&w=2
zstd тут не при чём. Это линукс деградирует ))
А можно в кратце в чем проблема? Я так понял, что в ядре что-то опять наколдовали с подсистемой памяти?
P.S. А есть ли разница межу SLUB / SLOB и т.д. в данном случае?
Там у них произошла "ломка неписанных правил", на которые закладывался reiser4. Раньше запрос с флагом GFP_KERNEL на выделение куска памяти не больше некоторого фиксированного размера никогда не возвращал ошибку. Теперь (через 15 лет), это отменили. Что у них там сейчас и как - я пока не разбирался, хотя это очень важно. В reiser4 есть пара мест, где ошибки аллокатора не могут быть обработаны. Одно из них в плагине (cryptcompress), который поддерживает сжатие. Ошибка возвращаемая методом ->alloc() of compression transform plugin сейчас обрабатывается - мы просто вставляем несжатые данные представленные одним буфером. А вот обрабатывать ошибку возвращаемую alloc_tfm_stream()(когда хотим 64К буфер, чтобы слить туда страницы перед компрессией) мы пока не можем. Для этого надо научиться вставлять в дерево несжатые данные, представленные несколькими неслитыми грязными страницами. Но это не так просто (я сам за это как-нибудь возьмусь).
So, someone work on Reiser4? In your interview (in 2010), you mentioned that there is only enough time to adaptive code for new versions of the kernel, but there is not enough time to develop the file system itself. So, something change? Can we hope for the future development of Reiser4?
Last edit: BratSinot 2017-11-07
Actually I do have 10-12 hours in a week for development.
So, a lot of things have been done for the past 7 years.
I push everything to development branches (unstable stuff):
https://github.com/edward6/reiser4/tree/format41
https://github.com/edward6/reiser4progs/tree/format41
Ну раз такое дело, то думаю на следующих выходных попробовать gzip / lzo / zstd.
Из тестов, собираюсь потестить линейную запись пустого файла (из /dev/zero), линейную запись несжимаемого файла (из /dev/urandom сделаю файл на tmpfs, и из tmpfs уже скопирую на раздел) и распаковку исходного кода ядра (будет tar архив на tmpfs).
С первым уровнем сжатия не пробовал, но он должен быть лучше gzip.
Last edit: BratSinot 2017-12-02