reiser4 metas/bmap problem

reiser4 metas/bmap problem

[Matt Stegman]

Hello,

I'm finally taking the time to start testing reiser4, and I'm running into
something odd.  Some of the time, reiser4 doesn't report a file's blocks
until I run 'sync'.  This shows up in metas/bmap as many blocks are
reported as 0.

# dd if=/dev/zero of=/mnt/reiser4/file bs=1M count=50
50+0 records in
50+0 records out
# chmod +x /mnt/reiser4/file
# grep '^0$' /mnt/reiser4/file/metas/bmap | wc -l
1792
# sleep 100
# grep '^0$' /mnt/reiser4/file/metas/bmap | wc -l
1792
# sync
# grep '^0$' /mnt/reiser4/file/metas/bmap | wc -l
0

I tried waiting to see if it gets written out in the background
asynchronously.  As you can see, it still shows up after a couple minutes,
so it doesn't appear to get written until an actual 'sync' command is run.
But it shows up inconsistently - many files don't show this.

The filefrag utility from e2fsprogs 1.35 also has problems with these
files, I believe it uses FIBMAP ioctl to get a blockmap of the file.

-- 
Matt Stegman

Re: reiser4 metas/bmap problem

[Andreas Dilger]

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

On Jul 28, 2004  18:26 -0500, Matt Stegman wrote:
> I'm finally taking the time to start testing reiser4, and I'm running into
> something odd.  Some of the time, reiser4 doesn't report a file's blocks
> until I run 'sync'.  This shows up in metas/bmap as many blocks are
> reported as 0.
> 
> # dd if=/dev/zero of=/mnt/reiser4/file bs=1M count=50
> 50+0 records in
> 50+0 records out
> # chmod +x /mnt/reiser4/file
> # grep '^0$' /mnt/reiser4/file/metas/bmap | wc -l
> 1792
> # sleep 100
> # grep '^0$' /mnt/reiser4/file/metas/bmap | wc -l
> 1792
> # sync
> # grep '^0$' /mnt/reiser4/file/metas/bmap | wc -l
> 0
> 
> I tried waiting to see if it gets written out in the background
> asynchronously.  As you can see, it still shows up after a couple minutes,
> so it doesn't appear to get written until an actual 'sync' command is run.
> But it shows up inconsistently - many files don't show this.

I believe one of the speedups of reiser4 is that it doesn't actually write
data to disk for minutes at a time, vs. 5s or so for most other filesystems.

The ext3_bmap() function flushes all file data to disk when called, and it
would be prudent to do the same with reiser4, since bmap users tend to be
important and not speed critical (e.g. lilo) and failing to do so can mean
not booting later.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/             http://members.shaw.ca/golinux/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: reiser4 metas/bmap problem

[Hans Reiser]

Andreas Dilger wrote:

>
>
>The ext3_bmap() function flushes all file data to disk when called, and it
>would be prudent to do the same with reiser4, since bmap users tend to be
>important and not speed critical (e.g. lilo) and failing to do so can mean
>not booting later.
>  
>
Interesting point.  vs, please comment.

Re: reiser4 metas/bmap problem

[Vladimir V. Saveliev]

Hello

Hans Reiser wrote:
> Andreas Dilger wrote:
> 
>>
>>
>> The ext3_bmap() function flushes all file data to disk when called, 
>> and it
>> would be prudent to do the same with reiser4, since bmap users tend to be
>> important and not speed critical (e.g. lilo) and failing to do so can 
>> mean
>> not booting later.
>>  
>>
> Interesting point.  vs, please comment.
> 
Yes, reiser4 might do something like that too. However, i am not sure how we can prevent relocation for files which were bmap-ed.

> 
> 

Re: reiser4 metas/bmap problem

[Vladimir V. Saveliev]

Andreas Dilger wrote:
> On Jul 28, 2004  18:26 -0500, Matt Stegman wrote:
> 
>>I'm finally taking the time to start testing reiser4, and I'm running into
>>something odd.  Some of the time, reiser4 doesn't report a file's blocks
>>until I run 'sync'.  This shows up in metas/bmap as many blocks are
>>reported as 0.
>>
>># dd if=/dev/zero of=/mnt/reiser4/file bs=1M count=50
>>50+0 records in
>>50+0 records out
>># chmod +x /mnt/reiser4/file
>># grep '^0$' /mnt/reiser4/file/metas/bmap | wc -l
>>1792
>># sleep 100
>># grep '^0$' /mnt/reiser4/file/metas/bmap | wc -l
>>1792
>># sync
>># grep '^0$' /mnt/reiser4/file/metas/bmap | wc -l
>>0
>>
>>I tried waiting to see if it gets written out in the background
>>asynchronously.  As you can see, it still shows up after a couple minutes,
>>so it doesn't appear to get written until an actual 'sync' command is run.
>>But it shows up inconsistently - many files don't show this.
> 
> 
> I believe one of the speedups of reiser4 is that it doesn't actually write
> data to disk for minutes at a time, vs. 5s or so for most other filesystems.
> 

The reason is actially that reiser4 does block allocation of flush. As for frequency of flushing - it is tunable via mount option.

> The ext3_bmap() function flushes all file data to disk when called, and it
> would be prudent to do the same with reiser4, since bmap users tend to be
> important and not speed critical (e.g. lilo) and failing to do so can mean
> not booting later.
> 

reiser4 should do the same, i agree. However, reiser4 has another feature we call relocation (flush may allocate another disk blocks for a file if it finds it 
more optimal) which is undesirable for bmapped files.
We will probably have to invent some woraround for that.

> Cheers, Andreas
> --
> Andreas Dilger
> http://sourceforge.net/projects/ext2resize/
> http://members.shaw.ca/adilger/             http://members.shaw.ca/golinux/
> 

Re: reiser4 metas/bmap problem

[daniel.poelzleithner]

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

Vladimir V. Saveliev wrote:

| reiser4 should do the same, i agree. However, reiser4 has another
| feature we call relocation (flush may allocate another disk blocks for a
| file if it finds it more optimal) which is undesirable for bmapped files.
| We will probably have to invent some woraround for that.

Whats about a flag that can be set through metas, that will prevent the
relocation ?
That would be no workaround, that would be a feature :)

regards
~ Daniel

- --
Once the philosopher stone has fallen from the tree,
~  nonsense appeared to fix the courious fear.

.. . .. ... . . .. . ... . .. . ... . . .
pgp key @ http://files.poelzi.org/pgp.txt
ED80 E53D 5269 4BB1 1E73 3A53 CBF9 A421 0A7B 003D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFBCbK8y/mkIQp7AD0RAtdYAJ4nvuykJ/jt22xaab8BWfnY1qSXzQCeO31N
O/J1M9fctbmDK3SiX/Ac7IE=
=wK7J
-----END PGP SIGNATURE-----

Re: reiser4 metas/bmap problem

[Andreas Dilger]

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

On Jul 30, 2004  04:30 +0200, daniel.poelzleithner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Vladimir V. Saveliev wrote:
> | reiser4 should do the same, i agree. However, reiser4 has another
> | feature we call relocation (flush may allocate another disk blocks for a
> | file if it finds it more optimal) which is undesirable for bmapped files.
> | We will probably have to invent some woraround for that.
> 
> Whats about a flag that can be set through metas, that will prevent the
> relocation ?  That would be no workaround, that would be a feature :)

Lilo knows to set "notail" on files that it is bmapping so that the tail
is unpacked into a real block that won't move.  That attribute could be
re-used for this purpose and all would be well.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/             http://members.shaw.ca/golinux/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: reiser4 metas/bmap problem

[Hans Reiser]

Vladimir V. Saveliev wrote:

> Hello
>
> Hans Reiser wrote:
>
>> Andreas Dilger wrote:
>>
>>>
>>>
>>> The ext3_bmap() function flushes all file data to disk when called, 
>>> and it
>>> would be prudent to do the same with reiser4, since bmap users tend 
>>> to be
>>> important and not speed critical (e.g. lilo) and failing to do so 
>>> can mean
>>> not booting later.
>>>  
>>>
>> Interesting point.  vs, please comment.
>>
> Yes, reiser4 might do something like that too. However, i am not sure 
> how we can prevent relocation for files which were bmap-ed.
>
>>
>>
>
>
>
>
fsync first and then bmap?

Re: reiser4 metas/bmap problem

[Andreas Dilger]

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

On Jul 30, 2004  11:37 -0700, Hans Reiser wrote:
> Vladimir V. Saveliev wrote:
> >Hans Reiser wrote:
> >>Andreas Dilger wrote:
> >>>The ext3_bmap() function flushes all file data to disk when called, 
> >>>and it would be prudent to do the same with reiser4, since bmap users
> >>>tend to be important and not speed critical (e.g. lilo) and failing
> >>>to do so can mean not booting later.
> >>> 
> >>Interesting point.  vs, please comment.
> >>
> >Yes, reiser4 might do something like that too. However, i am not sure 
> >how we can prevent relocation for files which were bmap-ed.
>
> fsync first and then bmap?

You could mark any file that had been bmapped as non-relocatable, and the
fsync too of course.  That may also be necessary for some kinds of crypto,
which use the block number as part of the key (not totally positive about
that but I recall something to this effect).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/             http://members.shaw.ca/golinux/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: reiser4 metas/bmap problem

[Vladimir V. Saveliev]

Hello

Hans Reiser wrote:
> Vladimir V. Saveliev wrote:
> 
>> Hello
>>
>> Hans Reiser wrote:
>>
>>> Andreas Dilger wrote:
>>>
>>>>
>>>>
>>>> The ext3_bmap() function flushes all file data to disk when called, 
>>>> and it
>>>> would be prudent to do the same with reiser4, since bmap users tend 
>>>> to be
>>>> important and not speed critical (e.g. lilo) and failing to do so 
>>>> can mean
>>>> not booting later.
>>>>  
>>>>
>>> Interesting point.  vs, please comment.
>>>
>> Yes, reiser4 might do something like that too. However, i am not sure 
>> how we can prevent relocation for files which were bmap-ed.
>>
>>>
>>>
>>
>>
>>
>>
> fsync first and then bmap?
> 
> 

It file will be later overwritten - flush may decide to relocate it.
So, if application which bmapped it will not re-bmap - there will be a confusion.

We need some way to mark file non-relocatable.

Re: reiser4 metas/bmap problem

[Christophe Saout]

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

Am Samstag, den 31.07.2004, 15:43 +0400 schrieb Vladimir V. Saveliev:

> >>>> The ext3_bmap() function flushes all file data to disk when called, 
> >>>> and it
> >>>> would be prudent to do the same with reiser4, since bmap users tend 
> >>>> to be
> >>>> important and not speed critical (e.g. lilo) and failing to do so 
> >>>> can mean
> >>>> not booting later.
> >>>>
> >>> Interesting point.  vs, please comment.
> >>>
> >> Yes, reiser4 might do something like that too. However, i am not sure 
> >> how we can prevent relocation for files which were bmap-ed.
> >>
> > fsync first and then bmap?
>
> It file will be later overwritten - flush may decide to relocate it.
> So, if application which bmapped it will not re-bmap - there will be a confusion.

Are there any applications which write into a file and expect the blocks
to stay at the same position? In case of lilo you have to rerun lilo
after writing a kernel because it might have changed in size. Usually
the old kernel has been moved any and not been overwritten anyway. My
personal opinion is that a filesystem sync (or implicit flusing when
bmap is called) should be enough.


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: reiser4 metas/bmap problem

[Vladimir V. Saveliev]

Hello

Christophe Saout wrote:
> Am Samstag, den 31.07.2004, 15:43 +0400 schrieb Vladimir V. Saveliev:
> 
> 
>>>>>>The ext3_bmap() function flushes all file data to disk when called, 
>>>>>>and it
>>>>>>would be prudent to do the same with reiser4, since bmap users tend 
>>>>>>to be
>>>>>>important and not speed critical (e.g. lilo) and failing to do so 
>>>>>>can mean
>>>>>>not booting later.
>>>>>>
>>>>>
>>>>>Interesting point.  vs, please comment.
>>>>>
>>>>
>>>>Yes, reiser4 might do something like that too. However, i am not sure 
>>>>how we can prevent relocation for files which were bmap-ed.
>>>>
>>>
>>>fsync first and then bmap?
>>
>>It file will be later overwritten - flush may decide to relocate it.
>>So, if application which bmapped it will not re-bmap - there will be a confusion.
> 
> 
> Are there any applications which write into a file and expect the blocks
> to stay at the same position?

I do not know

  In case of lilo you have to rerun lilo
> after writing a kernel because it might have changed in size. Usually
> the old kernel has been moved any and not been overwritten anyway. My
> personal opinion is that a filesystem sync (or implicit flusing when
> bmap is called) should be enough.
> 
yes, we will change reiser4_bmap that way