On May 07, 2007  21:43 -0400, Theodore Tso wrote:

quoted text
> On Mon, May 07, 2007 at 05:15:41PM -0700, Andrew Morton wrote:

> > Userspace could presumably repair the mess in most situations by truncating

> > the file back again.  The kernel cannot do that because there might be live

> > data in amongst there.

>

> Actually, the kernel could do it, in that could simply release all

> unitialized extents back to the system.  The problem is distinguishing

> between the unitialized extents that had just been newly added, versus

> the ones that had there from before.  (On the other hand, if the

> filesystem was completely full, releasing unitialized blocks wouldn't

> be the worse thing in the world to do, although releasing previously

> fallocated blocks probably does violate the princple of least

> surprise, even if it's what the user would have wanted.)

I tend to agree with this.  Having fallocate() fill up the filesystem

is exactly what the caller asked.  Doing a write() hit ENOSPC doesn't

trucate off the whole write either, nor does "dd" delete the whole file

when the filesystem is full.
Even checking the statfs() space before doing the fallocate() may be

counter intuitive, since it will return ENOSPC but the filesystem will

not actually be full.  Some applications (e.g. database) may WANT to

fill the filesystem and then get the actual file size back to avoid

trusting statfs() because of metadata overhead (e.g. indirect blocks).
One of the design goals for sys_fallocate() was to allow FA_DELALLOC

to deallocate unwritten extents in a safe manner.
Cheers, Andreas

--

Andreas Dilger

Principal Software Engineer

Cluster File Systems, Inc.
-

unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/