* tmpfs (documentation?) bug
@ 2005-11-02 5:00 Alexander E. Patrakov
2005-11-02 5:02 ` Alexander E. Patrakov
2005-11-02 22:57 ` Rob Landley
0 siblings, 2 replies; 6+ messages in thread
From: Alexander E. Patrakov @ 2005-11-02 5:00 UTC (permalink / raw)
To: LKML
Hello,
Documentation/filesystems/tmpfs.c currently says:
If nr_blocks=0 (or size=0), blocks will not be limited in that instance;
if nr_inodes=0, inodes will not be limited.
However, mounting a tmpfs with "mount -t tmpfs -o size=0 tmpfs
/root/tmpfs" results in a tmpfs where only zero-sized files can live. So
either this behaviour should be fixed to be in accordance with the
documentation, or the documentation should reflect the current behaviour.
--
Alexander E. Patrakov
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tmpfs (documentation?) bug
2005-11-02 5:00 tmpfs (documentation?) bug Alexander E. Patrakov
@ 2005-11-02 5:02 ` Alexander E. Patrakov
2005-11-02 22:58 ` Rob Landley
2005-11-02 22:57 ` Rob Landley
1 sibling, 1 reply; 6+ messages in thread
From: Alexander E. Patrakov @ 2005-11-02 5:02 UTC (permalink / raw)
To: Alexander E. Patrakov; +Cc: LKML
Alexander E. Patrakov wrote:
> Hello,
>
> Documentation/filesystems/tmpfs.c currently says:
>
> If nr_blocks=0 (or size=0), blocks will not be limited in that instance;
> if nr_inodes=0, inodes will not be limited.
>
> However, mounting a tmpfs with "mount -t tmpfs -o size=0 tmpfs
> /root/tmpfs" results in a tmpfs where only zero-sized files can live.
> So either this behaviour should be fixed to be in accordance with the
> documentation, or the documentation should reflect the current behaviour.
>
Please ignore, that applies to old kernels only, not to 2.6.14.
--
Alexander E. Patrakov
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tmpfs (documentation?) bug
2005-11-02 5:00 tmpfs (documentation?) bug Alexander E. Patrakov
2005-11-02 5:02 ` Alexander E. Patrakov
@ 2005-11-02 22:57 ` Rob Landley
1 sibling, 0 replies; 6+ messages in thread
From: Rob Landley @ 2005-11-02 22:57 UTC (permalink / raw)
To: Alexander E. Patrakov; +Cc: LKML
On Tuesday 01 November 2005 23:00, Alexander E. Patrakov wrote:
> Hello,
>
> Documentation/filesystems/tmpfs.c currently says:
>
> If nr_blocks=0 (or size=0), blocks will not be limited in that instance;
> if nr_inodes=0, inodes will not be limited.
>
> However, mounting a tmpfs with "mount -t tmpfs -o size=0 tmpfs
> /root/tmpfs" results in a tmpfs where only zero-sized files can live. So
> either this behaviour should be fixed to be in accordance with the
> documentation, or the documentation should reflect the current behaviour.
I like this behavior. Please keep this behavior. A dynamic /dev on tmpfs
should _only_ have dentries (device nodes and symlinks), no actual files.
I have a system that's currently using this to enforce that...
Rob
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tmpfs (documentation?) bug
2005-11-02 5:02 ` Alexander E. Patrakov
@ 2005-11-02 22:58 ` Rob Landley
2005-11-03 14:41 ` Hugh Dickins
0 siblings, 1 reply; 6+ messages in thread
From: Rob Landley @ 2005-11-02 22:58 UTC (permalink / raw)
To: Alexander E. Patrakov; +Cc: Alexander E. Patrakov, LKML
On Tuesday 01 November 2005 23:02, Alexander E. Patrakov wrote:
> Alexander E. Patrakov wrote:
> > Hello,
> >
> > Documentation/filesystems/tmpfs.c currently says:
> >
> > If nr_blocks=0 (or size=0), blocks will not be limited in that instance;
> > if nr_inodes=0, inodes will not be limited.
> >
> > However, mounting a tmpfs with "mount -t tmpfs -o size=0 tmpfs
> > /root/tmpfs" results in a tmpfs where only zero-sized files can live.
> > So either this behaviour should be fixed to be in accordance with the
> > documentation, or the documentation should reflect the current behaviour.
>
> Please ignore, that applies to old kernels only, not to 2.6.14.
So what's the new way to specify "this tmpfs mount should just be a directory
hierarchy with no data blocks" for those of us who _want_ the old behavior?
Rob
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tmpfs (documentation?) bug
2005-11-02 22:58 ` Rob Landley
@ 2005-11-03 14:41 ` Hugh Dickins
2005-11-03 18:36 ` Rob Landley
0 siblings, 1 reply; 6+ messages in thread
From: Hugh Dickins @ 2005-11-03 14:41 UTC (permalink / raw)
To: Rob Landley; +Cc: Alexander E. Patrakov, Alexander E. Patrakov, LKML
On Wed, 2 Nov 2005, Rob Landley wrote:
>
> So what's the new way to specify "this tmpfs mount should just be a directory
> hierarchy with no data blocks" for those of us who _want_ the old behavior?
Sorry about that. I guess you'll have to do the unaesthetic
mount -t tmpfs -o nr_blocks=1 tmpfs /mountpoint
echo full >/mountpoint/.full
Hugh
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tmpfs (documentation?) bug
2005-11-03 14:41 ` Hugh Dickins
@ 2005-11-03 18:36 ` Rob Landley
0 siblings, 0 replies; 6+ messages in thread
From: Rob Landley @ 2005-11-03 18:36 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Alexander E. Patrakov, Alexander E. Patrakov, LKML
On Thursday 03 November 2005 08:41, Hugh Dickins wrote:
> On Wed, 2 Nov 2005, Rob Landley wrote:
> > So what's the new way to specify "this tmpfs mount should just be a
> > directory hierarchy with no data blocks" for those of us who _want_ the
> > old behavior?
>
> Sorry about that. I guess you'll have to do the unaesthetic
>
> mount -t tmpfs -o nr_blocks=1 tmpfs /mountpoint
> echo full >/mountpoint/.full
Hmmm... I suppose as long as I have the sucker mounted "noexec" I can live
with that.
Rob
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-11-03 18:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-02 5:00 tmpfs (documentation?) bug Alexander E. Patrakov
2005-11-02 5:02 ` Alexander E. Patrakov
2005-11-02 22:58 ` Rob Landley
2005-11-03 14:41 ` Hugh Dickins
2005-11-03 18:36 ` Rob Landley
2005-11-02 22:57 ` Rob Landley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox