Keep in mind most of us don’t use our @fb.com addresses. LWN keeps track of companies by keeping track of who works where so our numbers are much higher than this list shows.
Applies across a bunch of companies (I use my IBM email but I know quite a few kernel devs here who prefer to keep their open source contributions under their personal email).
Host managed also means messing with the file system, and the patch set for btrfs is not small. Plus you have to disable a bunch of features (like preallocation since you can’t move the write pointer backwards) which is going to surprise people in unfun ways. These drives are useless for general purpose. If you are going to use them as expensive tape then by all means, but otherwise I have serious doubts about their usefulnes.
Edit: I’m talking specifically about the SMR side. The general zoned stuff is interesting, but when you start putting restrictions on how you can write to certain zones you wind up with a lot of weirdness that application developers are going to be surprised by.
Drive-managed SMR looks OK to me for general use, although I don't have hands-on experience with it. They also have a non-shingled region that can accept random I/O at higher speeds, and the drive deals with moving data to a linear-only region once it fills up, or at garbage collection time.
It's very much like the QLC drives where a portion is treated as SLC/MLC.
It's like the QLC drives with SLC/MLC cache (e.g., Intel 660p) except the performance cliff is far, far worse (and obviously the "fast" mode is far worse as well).
Some of the fallocate modes don't make much sense on CoW filesystems anyway. ZoL doesn't support preallocation either, you have to use FALLOC_FL_PUNCH_HOLE.
Lack of DIO might be a bigger issue. Then again it's often used by write-heavy workloads which probably don't want to use SMR drives anyway.
Not sure what you are talking about, it’s definitely endian neutral. You can’t take different page sized fs and put it on another page size arch, but that’s a separate issue.
2013 MIPS on Cavium as big endian -vs- Intel x86-64; appeared to work, did not. Page size not an issue, appeared to work, occasionally crazy with dumps containing values that are recognizably scrambled.
It's been awhile since then, but that was our experience. I don't have access to the records or email from the time. Maybe it's been fixed.
Cause it’s a summit to talk about the whole ecosystem, not one file system. We btrfs developers talk enough to each other, we don’t need to bore the rest of the attendees with our own topics. That’s what the hallway tracks are for. I put together the schedule for the file system side of this years conference, I specifically don’t put single fs issues on the general schedule.
It would be nice, but for complicated systems in the kernel you sometimes have to provide evidence that the old way sucks and the new way is better. With this work we can easily point at our production workloads and say the in kernel oom killer sucks and this new way is obviously better and hopefully work towards a better in kernel solution. That being said the user is always going to know what they care about more than the kernel, so being able to say “kill chef first, alway” can be a nice thing to have.
And then the uefi stub code in the Linux kernel, as well as the grub2 source code. It’s not too hard to figure out the flow in grub2, just figure out where it does EXIT_BOOT_SERVICES and work from there.
Facebook is using it for lots of shit. Chroots for containers because we can easily snapshot them and use them. Use it for build testing, so snapshot base repo, checkout commit, build, throw away. Gluster which takes huge backups and then other random workloads, it's used in a few places.
Just because Facebook is fault tolerant doesn't mean we don't care about failures. We actively run down any issues we hit, so while it doesn't have much of impact in the short term, we don't just ignore issues.
And also Red Hat hasn't contributed much to btrfs in years, and Oracle has one developer working on it. We are constantly working on it, and now that my priorities have shifted back to btrfs I hope that we will start to close out some of these long term projects.
Lol what? We don't ship code that isn't upstream. It sucks to maintain and rebase if you have a shitton of proprietary patches. Everything we do with the kernel is open source, you wouldn't be able to hire kernel developers if you didn't do open source. Nice comment tho, I legitimately lol'ed.
Sendfile isn't async, it just avoids the user space copy, and in some cases the copy from the fd to the socket. Aio doesn't require xfs, just O_DIRECT, which can be tricky to get right and more work than userspace guys want to deal with.
