[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080224065751.GA31293@lazybastard.org>
Date: Sun, 24 Feb 2008 07:57:52 +0100
From: Jörn Engel <joern@...fs.org>
To: David Woodhouse <dwmw2@...radead.org>
Cc: Pavel Machek <pavel@....cz>, linux-mtd@...ts.infradead.org,
kernel list <linux-kernel@...r.kernel.org>
Subject: Re: jffs2: -ENOSPC when truncating file?!
On Sun, 24 February 2008 09:36:07 +0900, David Woodhouse wrote:
> On Sun, 2008-02-24 at 00:57 +0100, Pavel Machek wrote:
> >
> > I'm trying to free space by truncating big file, and I get:
> >
> > root@...-gta01:~# ls -al gps.nmea
> > -rw-r--r-- 1 root root 2332070 Feb 19 22:13 gps.nmea
> > root@...-gta01:~# > gps.nmea
> > -sh: cannot create gps.nmea: No space left on device
> > root@...-gta01:~# rm gps.nmea
> > root@...-gta01:~# > gps.nmea
> > root@...-gta01:~#
>
> You need to write a log entry indicating the new length of the file.
> There is no space for new log entries.
>
> There is a special case for removal -- 'rm gps.nmea' would work. Perhaps
> we should add a special case for truncation too, so that it can also use
> the extra pool of free space.
Could a naïve implementation of this get exploited by doing a large
number of truncates that just shave single bytes off various files?
Looks like the safe way to do it would be to write out a replacement
node for the truncated node, if the special case ever triggers.
Jörn
--
"[One] doesn't need to know [...] how to cause a headache in order
to take an aspirin."
-- Scott Culp, Manager of the Microsoft Security Response Center, 2001
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists