Possible bug with FIBMAP

Possible bug with FIBMAP

[Brice Arnould]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

Hi

Two users of a hack I wrote told me that
http://vleu.net/shake/fb_r4.c (also attached with the mail)
returned "FIBMAP=-22, FIGETBSZ=4096"
on some of their files on reiser4 filesystems.

Does this value of "-22" have a special meaning (would be strange), or is it a 
bug in Reiser4 ?
I can ask them for more details, if you want.

Thanks
Brice

[-- Attachment #2: fb_r4.c --]
[-- Type: text/plain, Size: 809 bytes --]

/*
 * Non released test software, distributed under GPL-2 licence by
 * Brice Arnould (c) 2006
 * You shouldn't use it.
 */
#include <stdio.h>
#include <assert.h>		// assert()
#include <errno.h>		// errno
#include <error.h>		// error()
#include <sys/ioctl.h>		// ioctl()
#include <linux/fs.h>		// FIBMAP, FIGETBSZ
#include <sys/types.h>		// open()
#include <sys/stat.h>		// open()
#include <fcntl.h>		// open()

int
main (int argc, char **argv)
{
  int fd, blocksize, block = 0;
  if (1 != argc)
    error (1, 0, "usage : %s FILE", argv[0]);
  fd = open (argv[1], O_RDONLY);
  assert (0 < fd);
  if (-1 == ioctl (fd, FIGETBSZ, &blocksize)
      || -1 == ioctl (fd, FIBMAP, &block))
    error (1, 0, "ioctl() failed, are you root ?\n");
  printf ("FIBMAP=%i, FIGETBSZ=%i\n", block, blocksize);
  close (fd);
}

Re: Possible bug with FIBMAP

[Ivan Pulleyn]

-22 is EINVAL, or an invalid argument. Your file descriptor is
invalid, as proved by the assert().

Ivan...

On 8/27/06, Brice Arnould <un_brice@vleu.net> wrote:
> Hi
>
> Two users of a hack I wrote told me that
> http://vleu.net/shake/fb_r4.c (also attached with the mail)
> returned "FIBMAP=-22, FIGETBSZ=4096"
> on some of their files on reiser4 filesystems.
>
> Does this value of "-22" have a special meaning (would be strange), or is it a
> bug in Reiser4 ?
> I can ask them for more details, if you want.
>
> Thanks
> Brice
>
>
>

Re: Possible bug with FIBMAP

[Ivan Pulleyn]

Never mind, I misread the assert. :)

Ivan...

On 8/27/06, Ivan Pulleyn <ivan.pulleyn@gmail.com> wrote:
> -22 is EINVAL, or an invalid argument. Your file descriptor is
> invalid, as proved by the assert().
>
> Ivan...
>
> On 8/27/06, Brice Arnould <un_brice@vleu.net> wrote:
> > Hi
> >
> > Two users of a hack I wrote told me that
> > http://vleu.net/shake/fb_r4.c (also attached with the mail)
> > returned "FIBMAP=-22, FIGETBSZ=4096"
> > on some of their files on reiser4 filesystems.
> >
> > Does this value of "-22" have a special meaning (would be strange), or is it a
> > bug in Reiser4 ?
> > I can ask them for more details, if you want.
> >
> > Thanks
> > Brice
> >
> >
> >
>

Re: Possible bug with FIBMAP

[Hans Reiser]

zam, please review this unless vs is back.

What is the file size?  Is there anything special about the file (holes,
etc.)?

Thanks for finding what I assume is a bug.  (I wonder if this has been
sporadically affecting use of reiser4 with bootloaders.....)

Hans

Brice Arnould wrote:
> Hi
>
> Two users of a hack I wrote told me that
> http://vleu.net/shake/fb_r4.c (also attached with the mail)
> returned "FIBMAP=-22, FIGETBSZ=4096"
> on some of their files on reiser4 filesystems.
>
> Does this value of "-22" have a special meaning (would be strange), or is it a 
> bug in Reiser4 ?
> I can ask them for more details, if you want.
>
> Thanks
> Brice
>   
> ------------------------------------------------------------------------
>
> /*
>  * Non released test software, distributed under GPL-2 licence by
>  * Brice Arnould (c) 2006
>  * You shouldn't use it.
>  */
> #include <stdio.h>
> #include <assert.h>		// assert()
> #include <errno.h>		// errno
> #include <error.h>		// error()
> #include <sys/ioctl.h>		// ioctl()
> #include <linux/fs.h>		// FIBMAP, FIGETBSZ
> #include <sys/types.h>		// open()
> #include <sys/stat.h>		// open()
> #include <fcntl.h>		// open()
>
> int
> main (int argc, char **argv)
> {
>   int fd, blocksize, block = 0;
>   if (1 != argc)
>     error (1, 0, "usage : %s FILE", argv[0]);
>   fd = open (argv[1], O_RDONLY);
>   assert (0 < fd);
>   if (-1 == ioctl (fd, FIGETBSZ, &blocksize)
>       || -1 == ioctl (fd, FIBMAP, &block))
>     error (1, 0, "ioctl() failed, are you root ?\n");
>   printf ("FIBMAP=%i, FIGETBSZ=%i\n", block, blocksize);
>   close (fd);
> }
>   

Re: Possible bug with FIBMAP

[Alexander Zarochentsev]

On 27 August 2006 12:57, Brice Arnould wrote:
> Hi
>
> Two users of a hack I wrote told me that
> http://vleu.net/shake/fb_r4.c (also attached with the mail)
> returned "FIBMAP=-22, FIGETBSZ=4096"
> on some of their files on reiser4 filesystems.
>
> Does this value of "-22" have a special meaning (would be strange),
> or is it a bug in Reiser4 ?
> I can ask them for more details, if you want.

Reiser4: restore FIBMAP ioctl support for packed files

restore FIBMAP ioctl support for packed files,
don't report block numbers for not yet mapped to
disk nodes.

Signed-off-by: Alexander Zarochentsev <zam@namesys.com>
---
 fs/reiser4/plugin/item/item.c |    2 +-
 fs/reiser4/plugin/item/tail.c |    2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

--- linux-2.6-git.orig/fs/reiser4/plugin/item/item.c
+++ linux-2.6-git/fs/reiser4/plugin/item/item.c
@@ -614,7 +614,7 @@ item_plugin item_plugins[LAST_ITEM_ID] =
 				.write = reiser4_write_tail,
 				.read = reiser4_read_tail,
 				.readpage = readpage_tail,
-				.get_block = NULL,
+				.get_block = get_block_address_tail,
 				.append_key = append_key_tail,
 				.init_coord_extension =
 				init_coord_extension_tail
--- linux-2.6-git.orig/fs/reiser4/plugin/item/tail.c
+++ linux-2.6-git/fs/reiser4/plugin/item/tail.c
@@ -791,6 +791,8 @@ get_block_address_tail(const coord_t * c
 	assert("nikita-3252", znode_get_level(coord->node) == LEAF_LEVEL);
 
 	*block = *znode_get_block(coord->node);
+	if (reiser4_blocknr_is_fake(block))
+		*block = 0;
 	return 0;
 }
 

Re: Possible bug with FIBMAP

[Brice Arnould]

Le lundi 28 août 2006 10:33, Alexander Zarochentsev a écrit :
> Reiser4: restore FIBMAP ioctl support for packed files
>
> restore FIBMAP ioctl support for packed files,
> don't report block numbers for not yet mapped to
> disk nodes.

Thanks, I really couldn't fix this myself.
Keep up the good work !

Brice