12 ms·

Don't most of their problems go away when you fallocate a pile of space and use AIO+O_DIRECT like a database to get the buffer cache and most of the filesystem

Don't most of their problems go away when you fallocate a pile of space and use AIO+O_DIRECT like a database to get the buffer cache and most of the filesystem out of the way? CoW filesystems like BTRFS proviode ioctls to disable CoW as well, which would be useful here when you've grown your own. XFS has supported shutting off metadata like ctime/mtime updates for ages. If you jump through some hoops, with a fully allocated file, you can get a file on a filesystem to behave very closely to a bare block store.

notacoward 7y ago
> Don't most of their problems go away No. Yes, you can fallocate. Yes, you can use AIO, or even better io_uring. Yes, you can use O_DIRECT ... if you want to give up caching and have to deal with alignment restrictions, and it turns out that O_DIRECT turns into O_SYNC in some unexpected edge cases. That gets you something that kind of sort of behaves like a block device, but that doesn't solve any of the problems the authors identify. * No transactional semantics. Roll your own. (I'm actually OK with this one BTW, but others feel differently.) * No help with slow metadata operations. Still slow if you're still using multiple files, or roll your own within a single file. * No improvement in support for new media types (e.g. shingled/zoned). In an ideal world, local filesystems would do a decent job supporting distributed filesystems (and other data stores). Instead, we're in a world where local filesystems fall short in many ways, and the solution to every deficiency is to avoid the local filesystem as much as possible. That way leads to silos and lock-in, so I don't think it's a good answer. Local filesystems need to be better, or someone needs to create an equally standard abstraction and set of tools to do what local filesytems can't.

12 ms·

Don't most of their problems go away when you fallocate a pile of space and use AIO+O_DIRECT like a database to get the buffer cache and most of the filesystem

by newnewpdro 7y ago

notacoward 7y ago
> Don't most of their problems go away No. Yes, you can fallocate. Yes, you can use AIO, or even better io_uring. Yes, you can use O_DIRECT ... if you want to give up caching and have to deal with alignment restrictions, and it turns out that O_DIRECT turns into O_SYNC in some unexpected edge cases. That gets you something that kind of sort of behaves like a block device, but that doesn't solve any of the problems the authors identify. * No transactional semantics. Roll your own. (I'm actually OK with this one BTW, but others feel differently.) * No help with slow metadata operations. Still slow if you're still using multiple files, or roll your own within a single file. * No improvement in support for new media types (e.g. shingled/zoned). In an ideal world, local filesystems would do a decent job supporting distributed filesystems (and other data stores). Instead, we're in a world where local filesystems fall short in many ways, and the solution to every deficiency is to avoid the local filesystem as much as possible. That way leads to silos and lock-in, so I don't think it's a good answer. Local filesystems need to be better, or someone needs to create an equally standard abstraction and set of tools to do what local filesytems can't.