>Let's just consider the case of ordered writes, something we don't do
>right now but that we'l do in another few years. You may want to mark
>things dirty while holding a spinlock, for example, to guarantee that you
>get a cluster of ordered writes..
Why don't you want to use mark_dirty() for that? I am not against having a
way to avoid blocking, I am only proposing to make it a new way instead of
breaking the old interface.
While developing my filesystem I would like not having to think about the
VM and I would like to have everything autobalancing. It's true that
autobalancing will have a cost because we'll run balance_dirty more times,
but it's safe and simpler.
When I must do ordered writes I must be clever and so I'll want to use the
backdoor and _then_ call balance_dirty() by hand of course.
I am not totally worried about the current code but I guess we could have
new reports like the reiserfs one over the time (I was just waiting the
first one) maybe also not reproducible.
IMHO we should go safe and make a _new_ call that works without blocking.
>do te dirty balancing. In fact, I suspect that raiserfs should =really=
>try to use the common routines too - it will never beat the standard
>filesystems in performance if it doesn't (the old-fashioned way of having
Definitely agreed.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/