> > If I use kernel 2.4.10-pre4 and you explain your doubts
> > "apply-to-kernel-version-?" with "expanding-truncate" or "get_block for
> > 2.4.8" "what is not tested too much" but it works for you ... and you're
> > using kernel 2.4.7+ --> point me to the one I should use *now*, please.
>
> Try get_block patch.
>
> >
> > A --rebuild-tree before using the patch shouldn't be a problem, if
> > vmware+reiserfs won't fill my disk unnecessarily after a sudden low
> > battery on my notebook afterwards. So, for now, I didn't test one in the
> > lack of time for today.
> >
> > And, what I finally/originally meant is: What fills the hole of
> > 2.4.7-unlink-truncate-rename-rmdir.dif
> > (or what that patch made for vmware- and maybe soffice-useage)
> > ... for 2.4.10-preX ?!
> >
>
> "unlink.." patch and "get_block" (or "expanding truncate") patch solve
> different problems:
>
> "unlink.." patch
> Fixes long-standing problem in reiserfs, when disk space gets lost
> if crash occurred when some process hold a reference to an unlinked file.
>
> "get_block" (or "expanding truncate") is to fix wrong handling of races in
> reiserfs_writepage which occur when file is expanded by truncate and
> mmaped. That wrong handling of races is indicated by pap-5710 and
> vs-825 (of vs-: reiserfs_get_block: [XX YY0xZZ UNKNOWN] should not be
> found in older than 2.4.10-pre4). Note, that get_block patch still has
> pap-5710 (and few other additional printks I forgot to remove), but it
> should handle the races right.
>
> Did I answer your questions?
For me mostly, Yes.
But after all I can only repeat that you (the ReiserFS team) then should
force to build an "new" set of patches against 2.4.10-pre4 and 2.4.9-ac9 even
if there are some small problems with them, now.
If more people can do some testing on different cases you should faster find
the right solution.
I think two cases have to differenciate:
1. some space is lost during normal replay ---> do reiserfsck --rebuild-tree
2. randomly files get corrupted during replay ---> find them and delete them
:-(
I have some examples for the later case, here...
Thanks,
Dieter
