Re: Is there a "blackhole" /dev/null directory?

[Bodo Eggert]

Hans-Jürgen Koch <hjk@xxxxxxxxxxxxx> wrote:
> schrieb Jan Engelhardt <jengelh@xxxxxxxxxxxxxxx>:

>> There is a much more interesting 'problem' with a "/dev/null
>> directory".
>> 
>> Q: Why would you need such a directory?
>> A: To temporarily fool a program into believing it wrote something.
>> 
>> Q: Should all files disappear? (e.g. "unlink after open")
>> A: Maybe not, programs may stat() the file right afterwards and
>>    get confused by the "inexistence".
>> 
>> Q: What if a program attempts to mkdir /dev/nullmnt/foo to just
>>    create a file /dev/nullmnt/foo/barfile?
>> A: /dev/nullmnt/foo must continue to exist or be accepted for a while,
>>    or perhaps for eternity.
> 
> Well, the problem seems to be that a "directory" is not just data but
> also contains metadata. While it's easy to write data to /dev/null, you
> cannot simply discard metadata associated with a directory. So, such a
> "/dev/null-directory" would have to remember metadata (at least all
> created filenames including subdirectories) in the same way as other
> filesystems do. Only file _content_ can be discarded.
> To be honest, I still cannot see many sensible usecases for that...

Since both of you seem to know about the (possible) problems, maybe you can
take a look at my patch.

http://7eggert.dyndns.org:8080/tmp/autounlink.patch
(Not inline, because it would be duplicate in this thread.)
(Yes, this patch needs some cleanup. I just did checkpatch.)

First I thought I'd modify tmpfs to delete the file on O_CREAT, but it
turned out tmpfs will increase the dentry count in order to prevent the
delete-on-close effect. Skipping this step was allmost enough, I had to
prevent link() from pinning these files, too.

Some loops creating files or linking them did not show any decrease in
available memory, and to the best of my knowlege, I did not introduce new
memory leaks. And the best thing is: It's only 150 bytes of code. Not bad
for an additional mount flag, is it?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/