tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Path to kmods

In article <>,
Joerg Sonnenberger  <> wrote:
>On Sat, Nov 22, 2008 at 03:00:36PM -0500, Martin S. Weber wrote:
>> Who fixes softdeps? "It is going to be dropped and replaced
>> by WAPBL".
>I will pick this specific item as it is one of the things I am involved
>with. First of all, what is the problem with softdeps? It is a huge
>amount of code, it is complicating the whole FFS code and it is
>complicating the rest of the buffer code as well. In short, the softdep
>code as it is is very intrusive. It gives little to no advantage over a
>*working* WAPBL. Note that I don't say that WAPBL is correctly working
>right now, it has issues. Softdep due to its very nature depends on IO
>ordering contraints that are not available at least for consumer hard
>disks without completely killing performance and it will break in ways
>that are not obvious. So -- who might want to fix softdeps? Look at the
>code first. Do you want to provide patches? Do you want to compensate
>people for the pain needed to fix problems? Will you compensate people
>for effectively wasting time on a to-be-redundant feature just because
>it was once supported? It won't be dropped until WAPBL can hold up to
>the promises made.

I just had 3 consecutive panics "found inode" in the softdep code, by
repeatedly doing:

cd /lib
/rescue/rm -f && /rescue/ln -s

It takes a few repetitions for me, but it eventually happens. I just
turned off softdep.


Home | Main Index | Thread Index | Old Index