[BUG] fallocate behavior when crossing end-of-file

[BUG] fallocate behavior when crossing end-of-file

[Raskin Michael]

		Hello.
	I found the following bug in BtrFS:

	1. Create and open an empty file
	2. fallocate (fd, 0, 1)
	
Desired: something (probably, one block) is allocated/reserved for the
file. File length is set to 1 byte.

Actual: A block is allocated. File length is set to 1 block (4096
bytes). The rest of the file is filled with zeros.

	last_byte = min(extent_map_end(em), alloc_end);
	last_byte = (last_byte + mask) & ~mask;
	if (em->block_start == EXTENT_MAP_HOLE) {
		ret = prealloc_file_range(trans, inode, cur_offset,
				last_byte, locked_end + 1,
				alloc_hint, mode);

That part seems strange to me. You make an effort for block size to
divide last_byte. But last_byte should be
max(i_size_read(inode), offset+len)
- without any rounding.

Michael Raskin

Re: [BUG] fallocate behavior when crossing end-of-file

[Edward Shishkin]

Raskin Michael wrote:
> 		Hello.
>   

Hello.

> 	I found the following bug in BtrFS:
>
> 	1. Create and open an empty file
> 	2. fallocate (fd, 0, 1)
> 	
> Desired: something (probably, one block) is allocated/reserved for the
> file. File length is set to 1 byte.
>   
             
Where is it documented?

IMHO we should only guarantee that writes
to [0, 1] won't fail because of lack of disk space.
Other things (including file size) are up to implementation.

> Actual: A block is allocated. File length is set to 1 block (4096
> bytes). The rest of the file is filled with zeros.
>
> 	last_byte = min(extent_map_end(em), alloc_end);
> 	last_byte = (last_byte + mask) & ~mask;
> 	if (em->block_start == EXTENT_MAP_HOLE) {
> 		ret = prealloc_file_range(trans, inode, cur_offset,
> 				last_byte, locked_end + 1,
> 				alloc_hint, mode);
>
> That part seems strange to me. You make an effort for block size to
> divide last_byte. But last_byte should be
> max(i_size_read(inode), offset+len)
> - without any rounding.
>
> Michael Raskin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   

Re: [BUG] fallocate behavior when crossing end-of-file

[Chris Mason]

On Wed, 2009-05-06 at 16:59 +0200, Edward Shishkin wrote:
> Raskin Michael wrote:
> > 		Hello.
> >   
> 
> Hello.
> 
> > 	I found the following bug in BtrFS:
> >
> > 	1. Create and open an empty file
> > 	2. fallocate (fd, 0, 1)
> > 	
> > Desired: something (probably, one block) is allocated/reserved for the
> > file. File length is set to 1 byte.
> >   
>              
> Where is it documented?
> 
> IMHO we should only guarantee that writes
> to [0, 1] won't fail because of lack of disk space.
> Other things (including file size) are up to implementation.
> 

This one looks like a pretty simple bug in the fallocate call.  It is
rounding up the size to a block boundary.

-chris

> > Actual: A block is allocated. File length is set to 1 block (4096
> > bytes). The rest of the file is filled with zeros.
> >
> > 	last_byte = min(extent_map_end(em), alloc_end);
> > 	last_byte = (last_byte + mask) & ~mask;
> > 	if (em->block_start == EXTENT_MAP_HOLE) {
> > 		ret = prealloc_file_range(trans, inode, cur_offset,
> > 				last_byte, locked_end + 1,
> > 				alloc_hint, mode);
> >
> > That part seems strange to me. You make an effort for block size to
> > divide last_byte. But last_byte should be
> > max(i_size_read(inode), offset+len)
> > - without any rounding.
> >
> > Michael Raskin
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >   
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] fallocate behavior when crossing end-of-file

[Michael Raskin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Edward Shishkin wrote:
>> Desired: something (probably, one block) is allocated/reserved for the
>> file. File length is set to 1 byte.
>              
> Where is it documented?
> 
> IMHO we should only guarantee that writes
> to [0, 1] won't fail because of lack of disk space.
> Other things (including file size) are up to implementation.

POSIX, SUS.

http://www.opengroup.org/onlinepubs/009695399/functions/posix_fallocate.html

<<<
If the offset+ len is beyond the current file size, then
posix_fallocate() shall adjust the file size to offset+ len. Otherwise,
the file size shall not be changed.
>>>

Michael Raskin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBAgAGBQJKAajDAAoJEE6tnN0aWvw3umYH/Rhcs2m4UosPLOsSylVAiFiB
rRJbeYWX5xaw9wTCV7RW3BkAEM2gJ5De10j4x7g81L7GZQZNz3Pwu6WN+kQOrBnG
gSeCg7u5OpvJUrX6HxeJEeUOCg9VDzuTNyEWY3pUEo7L00MLuYqTQimg2pua3oAv
Ib7bUWVfRguxgQVO7pnw//CV6L+KBY7OP2za+c2x+Ec+KN0QsgAlYATxNP9+hI4o
VJL7nIGoAs5rZXkLuDJpQYgI2sl6yzZy1Jq0Q3+UnjDDLlU945yMQm4LGTEMMHJX
i/Ci58y+SNhiDFrPrW1nRCZXE0RiEk01hGTtVVI2yfZJz/dabZAtSgEbyp0k0/c=
=6Fmf
-----END PGP SIGNATURE-----

Re: [BUG] fallocate behavior when crossing end-of-file

[Edward Shishkin]

Michael Raskin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Edward Shishkin wrote:
>   
>>> Desired: something (probably, one block) is allocated/reserved for the
>>> file. File length is set to 1 byte.
>>>       
>>              
>> Where is it documented?
>>
>> IMHO we should only guarantee that writes
>> to [0, 1] won't fail because of lack of disk space.
>> Other things (including file size) are up to implementation.
>>     
>
> POSIX, SUS.
>
> http://www.opengroup.org/onlinepubs/009695399/functions/posix_fallocate.html
>
> <<<
> If the offset+ len is beyond the current file size, then
> posix_fallocate() shall adjust the file size to offset+ len. Otherwise,
> the file size shall not be changed.
>   

fallocate (2) is something different from posix_fallocate:

"...This default behavior closely resembles the behavior
of the posix_fallocate(3) library function, and is intended
as a method of optimally implementing that function."

Re: [BUG] fallocate behavior when crossing end-of-file

[Michael Raskin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Edward Shishkin wrote:
>> <<<
>> If the offset+ len is beyond the current file size, then
>> posix_fallocate() shall adjust the file size to offset+ len. Otherwise,
>> the file size shall not be changed.
>>   
> 
> fallocate (2) is something different from posix_fallocate:
> 
> "...This default behavior closely resembles the behavior
> of the posix_fallocate(3) library function, and is intended
> as a method of optimally implementing that function."

If you overincrement file size counter, the only way for glibc to
correctly implement is to ftruncate after fallocate . It doesn't look
like an optimal implementation of posix_fallocate (2 system calls). It
also doesn't look like something glibc would do. It currently doesn't.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBAgAGBQJKAfwBAAoJEE6tnN0aWvw3NQAH/2XFOZE/9MBAxySxOyNY9Gft
ttotQ4+g7SuKX47tQzskcWde3qbofEYzrsF/ADebjczEwbiKcZaJwlLzqL1X6siC
IWzBS8hIWbbKkyF2erQJP3QZEJq/IwRCK6bOj8EJckGJ6q6tLCIasXGs+GOAjhrB
1NWjDfprXP5M4s1xvG9KRH4Lo38Bz4/5w7ZGqGuXOy+M21ZHim+o9Tbkp7LaV9KP
OHqxgXV6tpHHv+Ai16cR1cJzY8XAIZ6EsL4lfpw7nZGlgRC+snccNdyoN3MltFOG
fbqIxrcPb8jL+3sAY+F1EK9oOKrCjQhY8VKxksy++M8+uP7OmgRiRkPyNewbYlw=
=fY9t
-----END PGP SIGNATURE-----