Martin Pelikan writes in with this report from g2k14:

My initial plan was to bring our base to a state where LLVM's libcpp could be compiled, giving us C++11 support. After I read up on the latest POSIX locale additions, other developers made it clear that more library version cranks will be necessary in order not to break ports. After the first diff was ready, I set up a base system build to check if it breaks. And then my life has changed...

Few days before the hackathon I decided to reinstall my laptop and put Linux, Windows and OpenBSD next to each other. One of the locale-related articles was left on the Linux partition and I wanted to open it in Austria, which is just full of tunnels without the internet. Our kernel didn't like the ext4; being too lazy to reboot, I decided to take a look at it "if I have a spare moment", which base builds certainly are.

No wonder -- ext4 uses extents, which weren't supported at that time. Quick look at FreeBSD showed they already have read-only support which became more or less functional on my OpenBSD kernel on Wednesday evening. No HTree directory indexes, no 64-bit block numbers, no journal or snapshots or multi-mount protection. But I could finally read the PDF without rebooting, and then also copy a file bigger than 4 GB or open a directory with 50,000 subdirectories in it. Never even looked at filesystem code before, and now a working port in a few hours? Life was great!

The question now was how to integrate it. OpenBSD developers don't like huge diffs for a very good reason. After fixing the inode format and adding new flags, Ted pointed out the ancient rule "whoever touched it last now becomes the maintainer" was valid even here. It was obvious I had to gain more knowledge by reading design papers and other systems' code before I can do valuable and correct commits. Legacy remnants like hard-coded (and wrong) limit on file sizes went first. Parts of the code were pretty badly comprehensible but FreeBSD has managed to split them up somehow. After our code paths looked similar enough, the ext4 extent support hit the tree.

Despite the fact that hackathons' purpose should be to write code, I had to literally learn to work with a subsystem I've only seen very vaguely once before (with FUSE). Because FreeBSD has already had these bits and getting them to work was so easy, this was a very good place to learn how to write filesystem code myself. During the next days I wrote code parsing and following the journal and ended up deliberately breaking my filesystem to observe what should we do about recovering it in seconds and how to order writes to support them in the future. Let's try to continue going down this road.

All this wouldn't have been possible without Phillip Guenther who reviewed my diffs after I kept distracting him from way more important things to do. Ted, Theo, Ken and Bob gave me lots of valuable input and explained how are things supposed to really work. Stephan Sperling gave me access to one of his sparc64 machines and gladly kept the tree up-to-date, so my breakages were relatively few and minor. Discussions about the network stack helped narrowing our focus to a direction and explaining our concerns about other solutions. Mitja must have been very busy with organizing the event so that things would go as well as they did. Well done everyone, thanks!

Now let's hope this filesystem enthusiasm will last longer, because now I need to switch back to GSoC in an area I'm already familiar with. Breaking my filesystem now will hopefully help repairing yours one day...

Мартин Пеликэн пишет в отчёте с g2k14:

Мой первоначальный план состоял в том, чтобы привести нашу базу в состояние, при котором libcpp LLVM мог быть собран, дав нам поддержку C++11. После того, как я читал о последних дополнениях локалей POSIX, другие разработчики прояснили, что будет нужно больше вариантов версии библиотеки, чтобы не сломать порты. После того, как первый diff был готов, я поднял сборку базовой системы, чтобы проверить, сломается ли она. И затем моя жизнь изменилась...

За несколько дней до хакатона я решил переустановить свой ноутбук, поместил туда Linux, Windows и OpenBSD рядом друг за другом. Одна из связанных с локалями статей была оставлена на разделе с Линуксом, и я хотел открыть её в Австрии, которая просто полна тоннелей без интернета. Наше ядро не любит ext4; будучи слишком ленивым для перезагрузки, я решил смотреть на неё как на то, "если у меня есть свободный момент".

Неудивительно - ext4 использует то, что не было поддерживаемым в то время. Беглый взгляд на OpenBSD показал, что у них уже есть поддержка только для чтения, которая стала более-менее функциональной на моём ядре OpenBSD в среду вечером. Нет индексов каталога HTree, нет 64-битных номеров блоков, нет журналов или снапшотов, или защиты от мульти-монтирования. Но я мог наконец прочитать PDF без перезагрузки и затем даже скопировать файл, больше, чем 4 ГБ, или открыть каталог с 50 000 подкаталогов в нём. Никогда прежде даже не смотрел на исходники файловой системы, а сейчас написал рабочий порт за несколько часов? Жизнь была прекрасна!

Теперь вопрос состоял в том, как его интегрировать. Разработчики OpenBSD не любят гигантские diffы, и на это есть серьёзное основание. После починки формата inode и добавления новых флагов, Тед указал на древнее правило "кто бы ни коснулся его теперь становится мейнтейнером", оно было действительно даже здесь. Это было очевидно, что я должен был получить больше знания, читая тексты дизайна и код других систем, прежде чем смогу делать ценные и правильные коммиты. Сначала пошли устаревшие остатки, похожие на трудно (и неправильно) закодированный лимит размеров файлов. Части кода понимались с трудом, но FreeBSD удалось их разделить, так или иначе. После этого наши пути кода выглядели достаточно похожими, поддержка ext4 поразила дерево.

Несмотря на то, что цель хакатона была в написании кода, я должен был буквально учиться работать с подсистемой, которую я видел очень неопределённо до этого однажды (c FUSE). Поскольку, у FreeBSD уже были эти биты, и заставить их работать было так просто, это было очень хорошее место, чтобы научиться писать код файловой системы самому. В течение следующих дней я написал парсинг кода, и, следуя журналу, закончил тем сознательно, ломая мою файловую систему, чтобы наблюдать то, что должны мы делать, восстанавливая её в секунды, и как сделать поддержку записи в будущем. Давайте попытаемся продолжить идти по этой дороге.

Всё это не было бы возможно без Филипа Гуентэра, который рассмотрел мои diffы после того, как я продолжал отвлекать его от более важных дел. Тед, Тео, Кен и Боб дали мне много ценного и объяснили, как вещи должны работать. Стефан Сперлинг дал мне доступ к одной из его sparc64 машин и с удовольствием держал дерево актуальным, таким образом, мои поломки были относительно небольшими и незначительными. Обсуждения о сетевом стеке помогли сузить наш фокус в направление и по поводу других решений. Митжа, должно быть, был очень занят организацией встречи, чтобы дела шли так, как им положено. Каждый всё сделал отлично, спасибо!

Теперь давайте надеяться, что этот энтузиазм насчёт файловой системы продолжится дольше, потому что я теперь должен переключиться назад на GSoC - в область, с которой я уже знаком. Порча моей файловой системы сейчас, надо надеяться, будет когда-нибудь помогать чинить вашу...