* RFC: guard against more "dangerous" userspace options
@ 2009-08-11 20:43 Eric Sandeen
2009-08-20 6:27 ` Aneesh Kumar K.V
0 siblings, 1 reply; 6+ messages in thread
From: Eric Sandeen @ 2009-08-11 20:43 UTC (permalink / raw)
To: ext4 development
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: guard against more "dangerous" userspace options
2009-08-11 20:43 RFC: guard against more "dangerous" userspace options Eric Sandeen
@ 2009-08-20 6:27 ` Aneesh Kumar K.V
2009-08-20 14:48 ` Eric Sandeen
0 siblings, 1 reply; 6+ messages in thread
From: Aneesh Kumar K.V @ 2009-08-20 6:27 UTC (permalink / raw)
To: Eric Sandeen; +Cc: ext4 development
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: guard against more "dangerous" userspace options
2009-08-20 6:27 ` Aneesh Kumar K.V
@ 2009-08-20 14:48 ` Eric Sandeen
2009-08-21 7:02 ` Aneesh Kumar K.V
0 siblings, 1 reply; 6+ messages in thread
From: Eric Sandeen @ 2009-08-20 14:48 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: ext4 development
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: guard against more "dangerous" userspace options
2009-08-20 14:48 ` Eric Sandeen
@ 2009-08-21 7:02 ` Aneesh Kumar K.V
2009-08-21 14:40 ` Eric Sandeen
2009-08-21 16:08 ` Andreas Dilger
0 siblings, 2 replies; 6+ messages in thread
From: Aneesh Kumar K.V @ 2009-08-21 7:02 UTC (permalink / raw)
To: Eric Sandeen; +Cc: ext4 development
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: guard against more "dangerous" userspace options
2009-08-21 7:02 ` Aneesh Kumar K.V
@ 2009-08-21 14:40 ` Eric Sandeen
2009-08-21 16:08 ` Andreas Dilger
1 sibling, 0 replies; 6+ messages in thread
From: Eric Sandeen @ 2009-08-21 14:40 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: ext4 development
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: guard against more "dangerous" userspace options
2009-08-21 7:02 ` Aneesh Kumar K.V
2009-08-21 14:40 ` Eric Sandeen
@ 2009-08-21 16:08 ` Andreas Dilger
1 sibling, 0 replies; 6+ messages in thread
From: Andreas Dilger @ 2009-08-21 16:08 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Eric Sandeen, ext4 development
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-08-21 16:08 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-11 20:43 RFC: guard against more "dangerous" userspace options Eric Sandeen
2009-08-20 6:27 ` Aneesh Kumar K.V
2009-08-20 14:48 ` Eric Sandeen
2009-08-21 7:02 ` Aneesh Kumar K.V
2009-08-21 14:40 ` Eric Sandeen
2009-08-21 16:08 ` Andreas Dilger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).