Arnd Bergmann wrote:
> On Saturday 31 May 2008, David Newall wrote:
>
>> I prefer the technique of union of a tmpfs over some other fs
>>
>
> You're right in principle, but unfortunately there is to date no working
> implementation of union mounts. Giving users the option of using an
> existing file system with a few tweaks can only be better than than
> forcing them to use hacks like unionfs.
I've not used unionfs (nor aufs) so I'm not aware of its foibles, but I
can say that it's the right kind of solution. Rather than spend effort
implementing write support for read-only filesystems, why not put your
time into fixing whatever you see wrong with one or both of those?
On Sunday 2008-06-01 08:02, David Newall wrote:
>>
>>> I prefer the technique of union of a tmpfs over some other fs
>>
>> You're right in principle, but unfortunately there is to date no working
>> implementation of union mounts. Giving users the option of using an
>> existing file system with a few tweaks can only be better than than
>> forcing them to use hacks like unionfs.
>
>I've not used unionfs (nor aufs) so I'm not aware of its foibles, but I
>can say that it's the right kind of solution. Rather than spend effort
>implementing write support for read-only filesystems, why not put your
>time into fixing whatever you see wrong with one or both of those?
I have to join in. Unionfs and AUFS may be bigger in bytes than the
embedded developer wants to sacrifice, but that is what it takes for
a solid implementation that has to deal with things like NFS and
mmap. Even so, there is a fs called mini_fo you can try using if
you disagree with the size of unionfs/aufs, at the cost of not having
support for all corner cases.
On Sun, 1 June 2008 15:32:50 +0930, David Newall wrote:
>
> I've not used unionfs (nor aufs) so I'm not aware of its foibles, but I
> can say that it's the right kind of solution. Rather than spend effort
> implementing write support for read-only filesystems, why not put your
> time into fixing whatever you see wrong with one or both of those?
There is a strong argument to be made for fixing some problem once
instead of N times. But when that solution is M times more complicated,
with M being significantly larger than N, said argument becomes rather
weak.
And having looked at unionfs, I claim that your argument is paper-thin.
Jörn
--
/* Keep these two variables together */
int bar;