We caught up with Jeff at a DevNation hackathon just before Red Hat Summit 2014 and gabbed about Gluster…and learned what it takes to be a storage developer.
Who are you?
I’m Jeff Darcy, the most senior developer on GlusterFS who was at Red Hat prior to the acquisition of Gluster.
Tell us about yourself
I came to Red Hat to start my own project based on GlusterFS. I’d been working on it for two years and was as surprised as anyone about the acquisition of Gluster. Rather than maintain two separate projects, it made a lot of sense for me to join Gluster’s architecture and development team and have my project absorbed into that.
Since then I’ve done a mix of hands-on and high-level thinking and evangelism. I’m probably the best-known blogger associated with GlusterFS. I’ve spent a lot of time over the past few years doing that and spreading the word at conferences.
I also created HekaFS, and even though the project is technically inactive, its web site is still very active —people still turn to it to find translators, even though I haven’t updated it in two years. It’s surprising that a lot of stuff I posted there is still popular, so I leave it there because it is useful to the community.
Why are you at the hackathon?
I’m here for the same reason I go to other events, which is to engage with whoever I can find and talk about what cool things we do with Gluster. Unfortunately, the barrier to entry to doing cool stuff with Gluster is high, but we’re fighting to draw people in.
What kind of people do you want to draw in?
Well, Gluster is storage technology. It’s written in frameworks and technologies that aren’t popular in our industry nowadays. It’s daunting, and you need a lot of background before you can do work. The ideal candidate is someone who is not daunted by that, who has done something similar before, and who has some storage related experience.
You also need some particular low-level or old fashioned skills. Gluster is a file system; it responds to requests that are familiar to people that have worked on file systems and contains surprises to people who haven’t. Not everyone has the understanding of what exactly are the semantics of writing data and calling fsyc, and there’s a lot of subtlety there. If you look at the documents that define these things in POSIX, they are pretty long and still incomplete. There’s an understanding that the file community has that isn’t well shared. We’re a pretty fearsome lot, and storage is something you absolutely positively have to get right.
People who have worked in storage for a long time are very wary of people who don’t understand storage and have given us a bad name. If someone loses data, they aren’t going to blame the responsible party, they’ll say “this kind of storage sucks.”
I remember when I started working in storage, I was used to the traditional view that a crash is the worst that can happen. Well, a crash is not the worst. Loss or corruption of data is the worst. Servers can come and go all day long as long as your data is still there. If you don’t have that mindset, it will be difficult to know why things in storage are the way they are. Our #1 mission is to ensure we are doing the correct thing, the data-preserving thing.