* Preventing FS full
@ 2010-10-28 14:24 Joakim Tjernlund
2010-10-28 14:39 ` David Woodhouse
2010-10-28 14:52 ` Artem Bityutskiy
0 siblings, 2 replies; 6+ messages in thread
From: Joakim Tjernlund @ 2010-10-28 14:24 UTC (permalink / raw)
To: linux-mtd
Is there any way to temporarily lower the FS full limit(preferably on a process basis)
on JFFS2?
I want to safeguard the OS from FS full due to some process filling up the disk.
Jocke
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Preventing FS full
2010-10-28 14:24 Preventing FS full Joakim Tjernlund
@ 2010-10-28 14:39 ` David Woodhouse
2010-10-28 15:31 ` Joakim Tjernlund
2010-10-28 14:52 ` Artem Bityutskiy
1 sibling, 1 reply; 6+ messages in thread
From: David Woodhouse @ 2010-10-28 14:39 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linux-mtd
On Thu, 2010-10-28 at 16:24 +0200, Joakim Tjernlund wrote:
> Is there any way to temporarily lower the FS full limit(preferably on
> a process basis) on JFFS2?
>
> I want to safeguard the OS from FS full due to some process filling up
> the disk.
The thresholds are in the resv_blocks_* variables and should be
relatively easy to tweak. I've toyed with the idea of exposing them in
sysfs. Tweaking them on a per-process basis is slightly less trivial but
shouldn't be that hard... you could add a certain number if the process
has CAP_SYS_RESOURCE or something.
Although it should *never* be possible to actually fill the space.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Preventing FS full
2010-10-28 14:39 ` David Woodhouse
@ 2010-10-28 15:31 ` Joakim Tjernlund
2010-10-28 21:34 ` David Woodhouse
0 siblings, 1 reply; 6+ messages in thread
From: Joakim Tjernlund @ 2010-10-28 15:31 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
David Woodhouse <dwmw2@infradead.org> wrote on 2010/10/28 16:39:08:
>
> On Thu, 2010-10-28 at 16:24 +0200, Joakim Tjernlund wrote:
> > Is there any way to temporarily lower the FS full limit(preferably on
> > a process basis) on JFFS2?
> >
> > I want to safeguard the OS from FS full due to some process filling up
> > the disk.
>
> The thresholds are in the resv_blocks_* variables and should be
> relatively easy to tweak. I've toyed with the idea of exposing them in
> sysfs. Tweaking them on a per-process basis is slightly less trivial but
> shouldn't be that hard... you could add a certain number if the process
> has CAP_SYS_RESOURCE or something.
Will have a look.
>
> Although it should *never* be possible to actually fill the space.
hmm, don't quite get that. Isn't it possible to write until the FS is full.
Surley you must at some pint return ENOSPC to user space and then you
cannot write more files. or ...?
Jocke
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Preventing FS full
2010-10-28 15:31 ` Joakim Tjernlund
@ 2010-10-28 21:34 ` David Woodhouse
0 siblings, 0 replies; 6+ messages in thread
From: David Woodhouse @ 2010-10-28 21:34 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linux-mtd
On Thu, 2010-10-28 at 17:31 +0200, Joakim Tjernlund wrote:
> hmm, don't quite get that. Isn't it possible to write until the FS is
> full.
> Surley you must at some pint return ENOSPC to user space and then you
> cannot write more files. or ...?
Oh, yeah -- that kind of full. Just not the *broken* kind of "eep,
there's no more space for GC" full :)
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Preventing FS full
2010-10-28 14:24 Preventing FS full Joakim Tjernlund
2010-10-28 14:39 ` David Woodhouse
@ 2010-10-28 14:52 ` Artem Bityutskiy
2010-10-28 14:54 ` Artem Bityutskiy
1 sibling, 1 reply; 6+ messages in thread
From: Artem Bityutskiy @ 2010-10-28 14:52 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linux-mtd
On Thu, 2010-10-28 at 16:24 +0200, Joakim Tjernlund wrote:
> Is there any way to temporarily lower the FS full limit(preferably on a process basis)
> on JFFS2?
>
> I want to safeguard the OS from FS full due to some process filling up the disk.
Mainstream FSes like ext3 can limit this on per-user or per-group basis,
and we had a similar thing for JFFS2, do not remember if we upstreamed
this, though. But I did send patches to the mtd ML.
FS has not idea about processes - the information about them is not
stored on the media, and it is very dynamic and unpredictable. I think
it is disaster to try to limit anything in the FS on per-process basis,
just makes little sense for me.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Preventing FS full
2010-10-28 14:52 ` Artem Bityutskiy
@ 2010-10-28 14:54 ` Artem Bityutskiy
0 siblings, 0 replies; 6+ messages in thread
From: Artem Bityutskiy @ 2010-10-28 14:54 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linux-mtd
On Thu, 2010-10-28 at 17:52 +0300, Artem Bityutskiy wrote:
> On Thu, 2010-10-28 at 16:24 +0200, Joakim Tjernlund wrote:
> > Is there any way to temporarily lower the FS full limit(preferably on a process basis)
> > on JFFS2?
> >
> > I want to safeguard the OS from FS full due to some process filling up the disk.
>
> Mainstream FSes like ext3 can limit this on per-user or per-group basis,
> and we had a similar thing for JFFS2, do not remember if we upstreamed
> this, though. But I did send patches to the mtd ML.
Hmm, no, probably my memory is bad, but it seems ext3 only has the
reserve for root, see mkfs.ext3 -m option.
In UBIFS you can specify user ID or group ID of the owner of the
reserve. And we had done the same for JFFS2 long time ago.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-10-28 21:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-28 14:24 Preventing FS full Joakim Tjernlund
2010-10-28 14:39 ` David Woodhouse
2010-10-28 15:31 ` Joakim Tjernlund
2010-10-28 21:34 ` David Woodhouse
2010-10-28 14:52 ` Artem Bityutskiy
2010-10-28 14:54 ` Artem Bityutskiy
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).