Btrfs is in mainline now.
Linus pulled this excellent filesystem into the vanilla tree. So if you were curious about how to extend your storage, this is a good way.
But beware, that it is a development tree and very likely contains fair number of errors you may encounter and thus lost the data.
Contrary to this we can check how Andrew Morton opposes to merge SquashFS (compressed read-only filesystem) because of not enough of testing (it is a default FS to build live CDs and installators for several years in all distros), not enough review (it passed three in the fsdevel maillist, although my trivials were not commented :), something else and (!) because it is called after a vegetable. I do hope Andrew made a joke about the last argument, even Linus entered the discussion, and now SquashFS is effectively merged, since Andrew agreed to pull it into the tree.
I’m curious what will happen when I will push POHMELFS upstream (and I will do it soon enough). Actually while I was writing this I decided to push it just tomorrow after documentation update. At least to ask Linus and Andrew, and you know, I can bet you there will be zero responses (related to the process), although POHMELFS is very competive already (although a bit younger than btrfs).
And although I’m pretty sure about the result, let’s do this for fun :)
Appartment development: the fireworks. The Main News.
Comments are currently closed.
Удачи!
Спасиб :)
> Actually while I was writing this I decided to push it just tomorrow after documentation update.
> At least to ask Linus and Andrew…
Please don’t.
Дальше я по-русски, так как с английским беда. Все дальнейшее — ИМХО.
Частые призывы к mainline merge без описания того, зачем и кому это _очень_ надо приведут к тому, что нужные люди будут их просто игнорировать (я надеюсь, пока еще не все так плохо). Потому что на самом деле всем все равно, насколько продвинутая технология задействована, или насколько крут и документирован код. Должна быть _простая_ причина, почему это всем нужно. Подтвержденная убийственными аргументами. Примеры — пожалуйста: Btrfs — ZFS для Linux, Squashfs — все это и так используют вместо того треша, что есть в ядре. Конечно, наличие такой причины не гарантирует мержа, но, и это важно, оно гарантирует появление прослойки людей, которые будут его добиваться. Потому, что они это реально для чего-то _используют_. Ну а best tool for the job рано или поздно окажется в ядре. Я в это верю :-) В случае с POHMELFS: я абсолютный ноль в распределенных файловых системах, поэтому попробую просто выдумать ответ на главный вопрос «почему она должна быть в ядре». Пример ответа: «Потому, что она в N раз быстрее NFS. Подробные бенчмарки следуют». Я думаю, проблема именно в том, что такого четкого ответа нет. Есть набор большой фишек, но какую картину в целом видят люди, прочитавшие их внушительный список? А при наличии такого четкого фокуса, люди видят: ага, да оно способно заменить мне NFS! Вот что главное! И дальше _они_ будут проталкивать POHMELFS в ядро.
Надеюсь, главная мысль не слишком размазана по тексту. На всякий случай, повторю :-) Напиши одним предложением, почему POHMELFS должна быть в ядре. Подкрепи это кучей подробных и крутых бенчмарков и тестов. Убери описание всех не связанных с этой главной темой фишек. «Продай» POHMELFS покруче. Сделай так, чтобы _другие_ добивались мержа (если его придется добиваться).
Удачи!
Actually yes, POHMELFS is several times faster than NFS in reading and 30-40% faster in writing, all benchmarks were presented several times here (and in the old blog). Current POHMELFS homepage contains fair amount of data why it should be used.
But high performance is only one of the feature POHMELFS has. The most important is its distributed capabilities being developed in the server. After it is ready I could say that all existing distributed filesystems (like lustre, pvfs, glusterfs, ceph and so on) become previous generation. But it is not not ready yet :)
Serious people like Jeff Garzik and Jamie Lokier were very interested in POHMELFS some time ago, not sure about current position though.
And actually I think I moved into the cathegory of the developers, who do created really complex and insteresting projects, but either because they are complex or I’m not from the club, they are not merged, but instead after some time someone else will implement similar (or simpler) idea. I wish I’m really wrong here :)
We will see. Thank you for the success wish.
Вообще да, POHMELFS в разы быстрее NFS на чтение и просто процентов на 30-40 быстрее на запись, бенчмарки были и неоднократно :)
Но это только “пол беды”, ее главным достоинством является разрабатываемый в данный момент сервер. По его окончании существующие распределенные системы (aka lustre, pvfs, glusterfs, ceph и т.д.) станут предыдущим поколением. И это объективно.
И есть серьезные люди, которые были заинтересованы в такой системе: Jeff Garzik и Jamie Lokier например.
Но есть мнение, что я уже попал в ту категорию разработчиков, которые делают серьезные вещи, которые не включаются в ядро, но которые служат основой дизайна для чьих-то других небольших патчей.
Спасибо за пожелания.
Да, да! Именно это я уже как-то советовал. Нужны use case-ы. Без них никто пальцем не будет шевелить. Нужно, чтобы все поняли зачем это нужно и где и как можно использовать и почему это лучше.
If you are wise you will push for 2.6.30, not 2.6.29, even if it’s ready now.
Trying to push it now won’t prove anything at all whatsoever.
And when going for 2.6.30, don’t just drop a new release, put them before a block: “This is ready for mainline merging, please pull it. If it isn’t, tell me what’s wrong with it.”
And keep your thoughts about the development process to yourself until after you pushed for mainline inclusion, and 2.6.30-rc1 was released without POHMELFS. Try to keep a positive attitude instead of assuming the worst. People are inconsistent, that’s how humans are. Live with it.
Better to aim for -next now or something, and them smoothly move into 2.6.30.
It’s good to be stubborn, but please be stubborn at the right time. :-)
Indan
(I liked your math captcha’s more…)
Yup, merge window is closed, I thought it is still there, but there is no more time.
Осталось завести и убить жену, да .__.
> Actually yes, POHMELFS is several times faster than NFS in reading and 30-40% faster in writing,
> all benchmarks were presented several times here (and in the old blog).
By the way, do you have any more recent benchs?
The latest I could find were done 6 months ago, so before you implemented proper locking and such.
And benchmarks showing how it does perform under concurrency/parallel (ie. one server, multiple clients threads) loads?
Это и есть обновление документации :)
Looks like the problem is that KERNEL IS GETTING BIG (in terms of code size). And popular. At these days everyone wants to include some of their code into the kernel. If everyone is allowed to do so without taking care why this code should be in kernel, kernel IMHO will collapse under it’s own excessive weight so kernel guys are probably already have hard times dealing with all this.
So to include something there should be a good reason. For btrfs I can see this: it’s modern CoW filesystem which has all chances to outperform older designs and offers many features missing in others. It even better than legendary ZFS. Squashfs is simply became used everywhere already. Without blessing of kernel developers. It used in tons of embedded devices like routers, NAS and similar.So since many people tired patching kernels or building modules and demand this feature it should appear in mainline. So, same goes for any other feature. If someone is willing to add even more bloat to already huge kernel there at least should be strong and clear reason why this have to be done. Putting each and every algorithm into kernel (even best ones) is a road to nowhere. All this will self-collapse under own excessive weight. After all there is modules and patches so everyone can put features and enjoy them and even allow others who needs this to do the same. And since there is awesome number of of people affected by changes in mainline and it’s increased bloat, it’s developers have to be careful with what being put into kernel by default and why it have to be in kernel at all. It may look like developers unfriendly but actually I’m thinking this is just usual weight issue which happens with each and every project once it goes big in code size and popular enough so everyone wants it to rock the world and also include certain super-cool functions like DoEverythingYouCanImagineAndEvenMore() and BringMeCoffeeIntoMyBedPlease(). If this allowed in unrestricted manner, project quickly reaches awful size, loses any maintainability and then usually dies by horrible death since everyone starts to hate it due to numerous bugs and impressive bloat and lack of possibility to fix all this in any acceptable time frame. Kernel developers are probably just trying to avoid this fate and this is surely good for everyone. So IMHO, as someone else sayd, if many people will demand some neat feature, great, it should be here. Otherwise… uhm, why not to make patches and\or modules, etc? This really allows everyone to be happy – mainline kernel do not have to grow in size but feature still available. The only thing I have to admit: it will be a real shame if there is really ‘the club’ and members of it will allow to uplift such restrictions for themselves. Though humans are always have problems with treating self equally to others and kernel developers are just humans, too…
> Да, да! Именно это я уже как-то советовал.
Так ведь правильно советовали.Кернель уже достиг опупенного размера.Поэтому если туда просто втыкать все что существует в природе – подохнет под своим же весом.И даже самый замечательный алгоритм без тех кто будет его использовать – всего лишь интересный артефакт для показа в музее.Так что имхо хорошо и здраво советуют.
А так вон орава народа юзает squashfs-lzma но в основной кернель если это и засунут – то далеко не сейчас из-за вполне понятных проблем.Для его юзежа надо засунуть в кернел lzma и т.п. – наверное это когда-то должно случиться но поскольку LZMA делался без учета такого использования – на это уйдет время.Кому надо сейчас позарез (те же производители роутеров и т.п.) – юзают патченые кернели и не разваливаются компильнуть модули.И далеко не факт что впихнуть все это в виде как есть сейчас в основной кернель – хорошая идея.А зачем всем остальным эти кривульки с ножом к горлу раздавать в основном ядре?
Actually, it’s probably the worst time (beside merge window being closed): all available block & fs reviewers eyeballs pairs are presently booked for btrfs audit, and it’s quite not sure they’ll recover for 2.6.30 even.
See, for instance, Christophe Hellwig reply to nilfs2 merge proposal, at the bottom of this mail:
http://marc.info/?l=linux-kernel&m=123128283515544&w=2
Yes, that’s a bit unfair with regards to POHMELFS, but really, there’s hope that at some point someone “authoritative” will finally review it and comment on the concepts (it does not take more before an iterative nitpicks-fixes-then-merge actually happens). So maybe there’s no point in burning your ammunitions just right now?
the name is completely wrong
it is long and not self-explaining
Do you mean squashfs or btrfs? Or ext4?
IMHO it is not the name which makes the project, although it also matters.
many linux developers love to give such names to their projects