I'll keep it short and sweet:
Can we add a consistent "--eatmydata" type of hurdle to jump over before
people are allowed to use either the so-far-less-tested tools and/or
options therein?
I'm thinking of, so far:
e4defrag
mkfs.ext4 -O meta_bg (?)
mkfs.ext4 -E lazy_itable_init=1
tune2fs -I <bigger>
without the --eatmydata option (feel free to edit for clarity) we could
get something like:
"The ____ option is experimental and/or incomplete, and should be used
only for testing at this point. Please re-issue your command with
'--eatmydata' option to use this option."
Thoughts?
I'm nervous about ext4 coming into wider use and people finding some of
the bits which aren't -quite- ready for prime time yet, and winding up
with a disaster.
Thanks,
-Eric
On Tue, Aug 11, 2009 at 03:43:24PM -0500, Eric Sandeen wrote:
> I'll keep it short and sweet:
>
> Can we add a consistent "--eatmydata" type of hurdle to jump over before
> people are allowed to use either the so-far-less-tested tools and/or
> options therein?
>
> I'm thinking of, so far:
......
> tune2fs -I <bigger>
I have sent patches which should make this better. Any chance to get that reviwed and
applied
-aneesh
Aneesh Kumar K.V wrote:
> On Tue, Aug 11, 2009 at 03:43:24PM -0500, Eric Sandeen wrote:
>> I'll keep it short and sweet:
>>
>> Can we add a consistent "--eatmydata" type of hurdle to jump over before
>> people are allowed to use either the so-far-less-tested tools and/or
>> options therein?
>>
>> I'm thinking of, so far:
> ......
>> tune2fs -I <bigger>
>
> I have sent patches which should make this better. Any chance to get that reviwed and
> applied
>
> -aneesh
Better, or _safe_? :)
No offense and I certainly appreciate that work. If you feel it's
robust enough now to safely unleash on users, I'll drop it from my list. :)
-Eric
On Thu, Aug 20, 2009 at 09:48:08AM -0500, Eric Sandeen wrote:
> Aneesh Kumar K.V wrote:
> > On Tue, Aug 11, 2009 at 03:43:24PM -0500, Eric Sandeen wrote:
> >> I'll keep it short and sweet:
> >>
> >> Can we add a consistent "--eatmydata" type of hurdle to jump over before
> >> people are allowed to use either the so-far-less-tested tools and/or
> >> options therein?
> >>
> >> I'm thinking of, so far:
> > ......
> >> tune2fs -I <bigger>
> >
> > I have sent patches which should make this better. Any chance to get that reviwed and
> > applied
> >
> > -aneesh
>
> Better, or _safe_? :)
>
> No offense and I certainly appreciate that work. If you feel it's
> robust enough now to safely unleash on users, I'll drop it from my list. :)
I am interested in the test results. Getting more users to test would always
be nice. But it still would help to get a through review.
-aneesh
Aneesh Kumar K.V wrote:
> On Thu, Aug 20, 2009 at 09:48:08AM -0500, Eric Sandeen wrote:
...
>>>> I'm thinking of, so far:
>>> ......
>>>> tune2fs -I <bigger>
>>> I have sent patches which should make this better. Any chance to get that reviwed and
>>> applied
>>>
>>> -aneesh
>> Better, or _safe_? :)
>>
>> No offense and I certainly appreciate that work. If you feel it's
>> robust enough now to safely unleash on users, I'll drop it from my list. :)
>
> I am interested in the test results. Getting more users to test would always
> be nice.
yep it's a tricky spot, asking users to test potentially dangerous code
in real life.
> But it still would help to get a through review.
Agree, sorry I haven't yet done that.
-Eric
>
> -aneesh
On Aug 21, 2009 12:32 +0530, Aneesh Kumar wrote:
> On Thu, Aug 20, 2009 at 09:48:08AM -0500, Eric Sandeen wrote:
> > Aneesh Kumar K.V wrote:
> > > On Tue, Aug 11, 2009 at 03:43:24PM -0500, Eric Sandeen wrote:
> > >> I'll keep it short and sweet:
> > >>
> > >> Can we add a consistent "--eatmydata" type of hurdle to jump over before
> > >> people are allowed to use either the so-far-less-tested tools and/or
> > >> options therein?
> > >>
> > >> I'm thinking of, so far:
> > > ......
> > >> tune2fs -I <bigger>
> > >
> > > I have sent patches which should make this better. Any chance to get
> > > that reviwed and applied
> >
> > Better, or _safe_? :)
> >
> > No offense and I certainly appreciate that work. If you feel it's
> > robust enough now to safely unleash on users, I'll drop it from my list. :)
>
> I am interested in the test results. Getting more users to test would always
> be nice. But it still would help to get a through review.
Adding an inode resize operation into the f_random_corruption test, or
into a similar test that runs with random mkfs parameters, would help
exercise the functionality in ways that a static test does not.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.