LKML Archive on
help / color / mirror / Atom feed
From: Bodo Eggert <>
To: "Hans-Jürgen Koch" <>,
	"Jan Engelhardt" <>,
	"Jasper Bryant-Greene" <>,
	rzryyvzy <>,,
Subject: Re: Is there a "blackhole" /dev/null directory?
Date: Fri, 15 Feb 2008 02:15:14 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hans-Jürgen Koch <> wrote:
> schrieb Jan Engelhardt <>:

>> 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.
(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?

  parent reply	other threads:[~2008-02-15  1:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2008-02-14 17:16 ` Bodo Eggert
     [not found] ` <>
     [not found]   ` <>
     [not found]     ` <>
     [not found]       ` <>
2008-02-15  1:15         ` Bodo Eggert [this message]
2008-02-14  9:30 rzryyvzy
2008-02-14  9:39 ` Jasper Bryant-Greene
2008-02-14  9:46   ` Andi Kleen
2008-02-14 15:00     ` Jan Engelhardt
2008-02-14 15:19       ` Hans-Jürgen Koch
2008-02-14 15:23         ` Jan Engelhardt
2008-02-14 15:30           ` Hans-Jürgen Koch
2008-02-15 19:25       ` Bill Davidsen
2008-02-14 12:16   ` Mika Lawando
2008-02-14 15:06     ` linux-os (Dick Johnson)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: Is there a "blackhole" /dev/null directory?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).