Hmmm. *screatches head* Why not adequately document it and mark it as
experimental. Configure.help has a purpose and it can be well used here.
You can have one para about what raiserfs is, the next para a huge warning
about possible consequences and then the next para about using it modular.
Alongside marking it experimental we can have a little comment stressing
to read the docs. We already do this:
[ ] Fast switching (read help!)
so why not with raiserfs?
Personally I'd like to start experimenting with it on /tmp and my squid
cache (for now at least) without the hassle of matching raiser patches
vs pre patches and so on. I -like- doing prepatches but don't want the
risk of possible incompatabilities and/or waiting for one to catch upto
the other. This, along with the comments re it needing to catch up to
the current way of doing things in the kernel (which I've noticed are
vanishing damned fast) are the two biggest things holding me back from
using it.
-- CaT (cat@zip.com.au) URL: http://www.zip.com.au/dev/null'He had position, but I was determined to score.' -- Worf, DS9, Season 5: 'Let He Who Is Without Sin...'
- 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/