Marc Espie wrote:
On Tue, Aug 02, 2016 at 02:53:43AM -0400, Eric Furman wrote:
...
Nope, I'm rather sure Theo doesn't care one way or the other.
I'm one of the guys who would very much like working tmpfs. Actually, it
has worked "good enough for me", but there are a few issues at work.
- I lack the time needed to fully dive into the kernel part.
- naddy did say multiple times it doesn't go all that fast compared to ffs
with ssd (well, I don't have a ssd on my build machines, so tmpfs is
marginally faster)
- there are loads of small nits in it that should properly be fixed.
Admittedly, I think a few good things came out of tmpfs. I've seen the fixes
(dabbled) for some of the problems, and in at least one case, the argument
check was moved up into the VFS layer.
In reality, every time I look at the VFS kernel layer, I get side-tracked
into thinking this is horrible code (the marshalling/unmarshalling of
parameters is very unnecessary, and doing pseudo inheritance by hand at the
function pointer level is horrible... there's a huge amount of weird
duplicated code in there... having three vfs structs for each fs based on
the type of file (normal file or otherwise) is rather strange, and I'm
reasonably certain some of the failure mode is dubious at best.
That said, it's on my long long list of things to try to play more with
eventually... but that list gets longer everyday, and Theo and other people
tend to add "priority" items to it that trump my ventures into kernel-land...
Well, tmpfs certainly lived up to its name. Introduced in 5.5 only to be
disabled in 6.0, there couldn't have been a more temporary file system.
