On Sun, 6 Oct 2019 10:18:11 -0700
Linus Torvalds wrote:
> On Sun, Oct 6, 2019 at 9:55 AM Theodore Y. Ts'o wrote:
> >
> > Well, one thing we *can* do is if (a) if we can create a kselftest
> > branch which we know is stable and won't change, and (b) we can get
> > assurances that Linus *will*
On Fri, Oct 04, 2019 at 03:59:10PM -0600, shuah wrote:
> On 10/4/19 3:42 PM, Linus Torvalds wrote:
> > On Fri, Oct 4, 2019 at 2:39 PM Theodore Y. Ts'o wrote:
> > >
> > > This question is primarily directed at Shuah and Linus
> > >
> > > What's the current status of the kunit series now that
Quoting Brendan Higgins (2019-08-14 03:03:47)
> On Tue, Aug 13, 2019 at 10:52 PM Brendan Higgins
> wrote:
> >
> > ## TL;DR
> >
> > This revision addresses comments from Stephen and Bjorn Helgaas. Most
> > changes are pretty minor stuff that doesn't affect the API in anyway.
> > One significant
On Fri, Jun 21, 2019 at 08:59:48AM -0600, shuah wrote:
> > > ### But wait! Doesn't kselftest support in kernel testing?!
> > >
> > >
>
> I think I commented on this before. I agree with the statement that
> there is no overlap between Kselftest and KUnit. I would like see this
> removed.
On Wed, May 22, 2019 at 02:38:48PM -0700, Brendan Higgins wrote:
> +Bjorn Helgaas
>
> On Wed, May 15, 2019 at 12:41 AM Daniel Vetter wrote:
> >
> > On Tue, May 14, 2019 at 11:36:18AM -0700, Brendan Higgins wrote:
> > > On Tue, May 14, 2019 at 02:05:05PM +0200, Daniel Vetter wrote:
> > > > On
On Tue, May 14, 2019 at 11:36:18AM -0700, Brendan Higgins wrote:
> On Tue, May 14, 2019 at 02:05:05PM +0200, Daniel Vetter wrote:
> > On Tue, May 14, 2019 at 8:04 AM Brendan Higgins
> > wrote:
> > >
> > > On Mon, May 13, 2019 at 04:44:51PM +0200, Daniel Vetter wrote:
> > > > On Sat, May 11, 2019
s/testing/selftests/uevent/uevent_filtering.c
>
>
> > Thus, I can personally see a lot of value in integrating the kunit
> > test framework with this kselftest harness. There's only a small
> > number of users of the kselftest harness today, so one way or another
> > it s
On Sat, May 11, 2019 at 08:43:23AM +0200, Knut Omang wrote:
> On Fri, 2019-05-10 at 14:59 -0700, Frank Rowand wrote:
> > On 5/10/19 3:23 AM, Brendan Higgins wrote:
> > >> On Fri, May 10, 2019 at 7:49 AM Knut Omang wrote:
> > >>>
> > >>> On Thu, 2019-05-09 at 22:18 -0700, Frank Rowand wrote:
> >
On Sat, May 11, 2019 at 01:33:44PM -0400, Theodore Ts'o wrote:
> On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote:
> > However, the reply is incorrect. Kselftest in-kernel tests (which
> > is the context here) can be configured as built in instead of as
> > a module, and built in a
On 5/9/19 3:20 PM, Logan Gunthorpe wrote:
>
>
> On 2019-05-09 3:42 p.m., Theodore Ts'o wrote:
>> On Thu, May 09, 2019 at 11:12:12AM -0700, Frank Rowand wrote:
>>>
>>> "My understanding is that the intent of KUnit is to avoid booting a
>>> kernel on
>>> real hardware or in a virtual
t; > we would merge through your tree when the time came? Am I remembering
> > correctly?
> >
> > ## Background
> >
> > This patch set proposes KUnit, a lightweight unit testing and mocking
> > framework for the Linux kernel.
> >
> > Unlike Autotes
On Fri, May 10, 2019 at 7:49 AM Knut Omang wrote:
>
> On Thu, 2019-05-09 at 22:18 -0700, Frank Rowand wrote:
> > On 5/9/19 4:40 PM, Logan Gunthorpe wrote:
> > >
> > >
> > > On 2019-05-09 5:30 p.m., Theodore Ts'o wrote:
> > >> On Thu, May 09, 2019 at 04:20:05PM -0600, Logan Gunthorpe wrote:
> >
On Thu, May 9, 2019 at 7:00 PM wrote:
> > -Original Message-
> > From: Theodore Ts'o
> >
> > On Thu, May 09, 2019 at 01:52:15PM +0200, Knut Omang wrote:
> > > 1) Tests that exercises typically algorithmic or intricate, complex
> > >code with relatively few outside dependencies, or
e came? Am I remembering
> correctly?
>
> ## Background
>
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
>
> Unlike Autotest and kselftest, KUnit is a true unit testing framework;
> it does not require installing
On Wed, 2019-05-08 at 23:20 -0400, Theodore Ts'o wrote:
> On Wed, May 08, 2019 at 07:13:59PM -0700, Frank Rowand wrote:
> > > If you want to use vice grips as a hammer, screwdriver, monkey wrench,
> > > etc. there's nothing stopping you from doing that. But it's not fair
> > > to object to other
On 5/8/19 6:44 PM, Theodore Ts'o wrote:
> On Wed, May 08, 2019 at 05:58:49PM -0700, Frank Rowand wrote:
>>
>> If KUnit is added to the kernel, and a subsystem that I am submitting
>> code for has chosen to use KUnit instead of kselftest, then yes, I do
>> *have* to use KUnit if my submission needs
> On Tue, May 07, 2019 at 10:01:19AM +0200, Greg KH wrote:
> > > My understanding is that the intent of KUnit is to avoid booting a kernel
> > > on
> > > real hardware or in a virtual machine. That seems to be a matter of
> > > semantics
> > > to me because isn't invoking a UML Linux just
On Fri, May 3, 2019 at 7:38 AM shuah wrote:
>
> On 5/1/19 5:01 PM, Brendan Higgins wrote:
> > Add myself as maintainer of KUnit, the Linux kernel's unit testing
> > framework.
> >
> > Signed-off-by: Brendan Higgins
> > ---
> > MAINTAINERS | 10
On 5/1/19 5:01 PM, Brendan Higgins wrote:
Add myself as maintainer of KUnit, the Linux kernel's unit testing
framework.
Signed-off-by: Brendan Higgins
---
MAINTAINERS | 10 ++
1 file changed, 10 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5c38f21aee787..c78ae95c56b80
t; since there seems to be general consensus about
> > everything at a high level, with a couple exceptions.
> >
> > At this time I am planning on sending the next revision out as "[PATCH
> > v1 00/NN] kunit: introduce KUnit, the Linux kernel unit testing
> &
On 2019-03-20 11:23 p.m., Knut Omang wrote:
> Testing drivers, hardware and firmware within production kernels was the use
> case that inspired KTF (Kernel Test Framework). Currently KTF is available as
> a
> standalone git repository. That's been the most efficient form for us so far,
> as
e2cd30e-goog
>
Someone suggested I should send the next revision out as "PATCH"
instead of "RFC" since there seems to be general consensus about
everything at a high level, with a couple exceptions.
At this time I am planning on sending the next revision out as "[PA
On Fri, Feb 22, 2019 at 12:53 PM Thiago Jung Bauermann
wrote:
>
>
> Frank Rowand writes:
>
> > On 2/19/19 10:34 PM, Brendan Higgins wrote:
> >> On Mon, Feb 18, 2019 at 12:02 PM Frank Rowand
> >> wrote:
> >>
> >>> I have not read through the patches in any detail. I have read some of
> >>>
On Tue, Feb 19, 2019 at 10:46 PM Frank Rowand wrote:
>
> On 2/19/19 10:34 PM, Brendan Higgins wrote:
> > On Mon, Feb 18, 2019 at 12:02 PM Frank Rowand
> > wrote:
> >
> >> I have not read through the patches in any detail. I have read some of
> >> the code to try to understand the patches to
Frank Rowand writes:
> On 2/19/19 10:34 PM, Brendan Higgins wrote:
>> On Mon, Feb 18, 2019 at 12:02 PM Frank Rowand wrote:
>>
>>> I have not read through the patches in any detail. I have read some of
>>> the code to try to understand the patches to the devicetree unit tests.
>>> So that
On 2/19/19 10:34 PM, Brendan Higgins wrote:
> On Mon, Feb 18, 2019 at 12:02 PM Frank Rowand wrote:
>
>> I have not read through the patches in any detail. I have read some of
>> the code to try to understand the patches to the devicetree unit tests.
>> So that may limit how valid my comments
On Mon, Feb 18, 2019 at 12:02 PM Frank Rowand wrote:
> I have not read through the patches in any detail. I have read some of
> the code to try to understand the patches to the devicetree unit tests.
> So that may limit how valid my comments below are.
No problem.
>
> I found the code
On 2/14/19 1:37 PM, Brendan Higgins wrote:
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
>
> Unlike Autotest and kselftest, KUnit is a true unit testing framework;
> it does not require installing the kernel on a test mac
Add myself as maintainer of KUnit, the Linux kernel's unit testing
framework.
Signed-off-by: Brendan Higgins
---
MAINTAINERS | 10 ++
1 file changed, 10 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8c68de3cfd80e..ff2cc9fcb49ad 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
This patch set proposes KUnit, a lightweight unit testing and mocking
framework for the Linux kernel.
Unlike Autotest and kselftest, KUnit is a true unit testing framework;
it does not require installing the kernel on a test machine or in a VM
and does not require tests to be written in userspace
On Wed, Oct 17, 2018 at 4:12 PM Randy Dunlap wrote:
>
> On 10/16/18 4:50 PM, Brendan Higgins wrote:
> > This patch set proposes KUnit, a lightweight unit testing and mocking
> > framework for the Linux kernel.
>
> Hi,
>
> Just a general comment:
>
> Documentation/process/submitting-patches.rst
On Wed, Oct 17, 2018 at 4:12 PM Randy Dunlap wrote:
>
> On 10/16/18 4:50 PM, Brendan Higgins wrote:
> > This patch set proposes KUnit, a lightweight unit testing and mocking
> > framework for the Linux kernel.
>
> Hi,
>
> Just a general comment:
>
> Documentation/process/submitting-patches.rst
On 10/16/18 4:50 PM, Brendan Higgins wrote:
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
Hi,
Just a general comment:
Documentation/process/submitting-patches.rst says:
<>
That also means saying things like:
... test: add
instead of
On 10/16/18 4:50 PM, Brendan Higgins wrote:
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
Hi,
Just a general comment:
Documentation/process/submitting-patches.rst says:
<>
That also means saying things like:
... test: add
instead of
kernel might benefit from this,
> but I have lots of questions.
>
Awesome!
> > Unlike Autotest and kselftest, KUnit is a true unit testing framework;
> > it does not require installing the kernel on a test machine or in a VM
> > and does not require tests to be written in us
kernel might benefit from this,
> but I have lots of questions.
>
Awesome!
> > Unlike Autotest and kselftest, KUnit is a true unit testing framework;
> > it does not require installing the kernel on a test machine or in a VM
> > and does not require tests to be written in us
On Tue, Oct 16, 2018 at 6:53 PM Brendan Higgins
wrote:
>
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
>
> Unlike Autotest and kselftest, KUnit is a true unit testing framework;
> it does not require installing th
On Tue, Oct 16, 2018 at 6:53 PM Brendan Higgins
wrote:
>
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
>
> Unlike Autotest and kselftest, KUnit is a true unit testing framework;
> it does not require installing th
test and kselftest, KUnit is a true unit testing framework;
> it does not require installing the kernel on a test machine or in a VM
> and does not require tests to be written in userspace running on a host
> kernel.
This is stated here and a few places in the documentation. Just to clarif
test and kselftest, KUnit is a true unit testing framework;
> it does not require installing the kernel on a test machine or in a VM
> and does not require tests to be written in userspace running on a host
> kernel.
This is stated here and a few places in the documentation. Just to clarif
Added myself as maintainer of KUnit, the Linux kernel's unit testing
framework.
Signed-off-by: Brendan Higgins
---
MAINTAINERS | 15 +++
1 file changed, 15 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 544cac829cf44..9c3d34f0062ad 100644
--- a/MAINTAINERS
+++ b
Added myself as maintainer of KUnit, the Linux kernel's unit testing
framework.
Signed-off-by: Brendan Higgins
---
MAINTAINERS | 15 +++
1 file changed, 15 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 544cac829cf44..9c3d34f0062ad 100644
--- a/MAINTAINERS
+++ b
This patch set proposes KUnit, a lightweight unit testing and mocking
framework for the Linux kernel.
Unlike Autotest and kselftest, KUnit is a true unit testing framework;
it does not require installing the kernel on a test machine or in a VM
and does not require tests to be written in userspace
This patch set proposes KUnit, a lightweight unit testing and mocking
framework for the Linux kernel.
Unlike Autotest and kselftest, KUnit is a true unit testing framework;
it does not require installing the kernel on a test machine or in a VM
and does not require tests to be written in userspace
On Tue, Oct 10, 2017 at 08:09:20AM +1100, Dave Chinner wrote:
> > I'd _like_ to expand fio for cases we come up with that aren't possible, as
> > there's already a ton of measurements that are taken, especially around
> > latencies.
>
> To be properly useful it needs to support more than just fio
On Tue, Oct 10, 2017 at 08:09:20AM +1100, Dave Chinner wrote:
> > I'd _like_ to expand fio for cases we come up with that aren't possible, as
> > there's already a ton of measurements that are taken, especially around
> > latencies.
>
> To be properly useful it needs to support more than just fio
On Tue, Oct 10, 2017 at 08:09:20AM +1100, Dave Chinner wrote:
> On Mon, Oct 09, 2017 at 09:00:51AM -0400, Josef Bacik wrote:
> > On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote:
> > > On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
> > > > > Integrating into fstests means
On Tue, Oct 10, 2017 at 08:09:20AM +1100, Dave Chinner wrote:
> On Mon, Oct 09, 2017 at 09:00:51AM -0400, Josef Bacik wrote:
> > On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote:
> > > On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
> > > > > Integrating into fstests means
On Mon, Oct 09, 2017 at 09:00:51AM -0400, Josef Bacik wrote:
> On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote:
> > On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
> > > > Integrating into fstests means it will be immediately available to
> > > > all fs developers, it'll
On Mon, Oct 09, 2017 at 09:00:51AM -0400, Josef Bacik wrote:
> On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote:
> > On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
> > > > Integrating into fstests means it will be immediately available to
> > > > all fs developers, it'll
On Mon, Oct 09, 2017 at 08:54:16AM -0400, Josef Bacik wrote:
> I purposefully used as little as possible, just json and sqlite, and I tried
> to
> use as little python3 isms as possible. Any rpm based systems should have
> these
> libraries already installed, I agree that using any of the PyPI
On Mon, Oct 09, 2017 at 08:54:16AM -0400, Josef Bacik wrote:
> I purposefully used as little as possible, just json and sqlite, and I tried
> to
> use as little python3 isms as possible. Any rpm based systems should have
> these
> libraries already installed, I agree that using any of the PyPI
On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote:
> One thing that comes up a lot every LSF is the fact that we have no general
> way
> that we do performance testing. Every fs developer has a set of scripts or
> things that they run with varying degrees of consistency, but nothing
On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote:
> One thing that comes up a lot every LSF is the fact that we have no general
> way
> that we do performance testing. Every fs developer has a set of scripts or
> things that they run with varying degrees of consistency, but nothing
On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote:
> On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
> > On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote:
> > > On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote:
> > > > Hello,
> > > >
> > > > One
On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote:
> On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
> > On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote:
> > > On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote:
> > > > Hello,
> > > >
> > > > One
On Sun, Oct 08, 2017 at 11:43:35PM -0400, Theodore Ts'o wrote:
> On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
> >
> > Probably should have led with that shouldn't I have? There's nothing
> > keeping me
> > from doing it, but I didn't want to try and shoehorn in a python thing
On Sun, Oct 08, 2017 at 11:43:35PM -0400, Theodore Ts'o wrote:
> On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
> >
> > Probably should have led with that shouldn't I have? There's nothing
> > keeping me
> > from doing it, but I didn't want to try and shoehorn in a python thing
On Mon, Oct 09, 2017 at 02:54:34PM +0800, Eryu Guan wrote:
> I have no problem either if python is really needed, after all this is a
> very useful infrastructure improvement. But the python version problem
> brought up by Ted made me a bit nervous, we need to work that round
> carefully.
>
>
On Mon, Oct 09, 2017 at 02:54:34PM +0800, Eryu Guan wrote:
> I have no problem either if python is really needed, after all this is a
> very useful infrastructure improvement. But the python version problem
> brought up by Ted made me a bit nervous, we need to work that round
> carefully.
>
>
On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote:
> On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
> > On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote:
> > > On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote:
> > > > Hello,
> > > >
> > > > One
On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote:
> On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
> > On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote:
> > > On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote:
> > > > Hello,
> > > >
> > > > One
On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
> On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote:
> > On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote:
> > > Hello,
> > >
> > > One thing that comes up a lot every LSF is the fact that we have no
> > > general
On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
> On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote:
> > On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote:
> > > Hello,
> > >
> > > One thing that comes up a lot every LSF is the fact that we have no
> > > general
On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
>
> Probably should have led with that shouldn't I have? There's nothing keeping
> me
> from doing it, but I didn't want to try and shoehorn in a python thing into
> fstests. I need python to do the sqlite and the json parsing to
On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
>
> Probably should have led with that shouldn't I have? There's nothing keeping
> me
> from doing it, but I didn't want to try and shoehorn in a python thing into
> fstests. I need python to do the sqlite and the json parsing to
On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote:
> On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote:
> > Hello,
> >
> > One thing that comes up a lot every LSF is the fact that we have no general
> > way
> > that we do performance testing. Every fs developer has a set of
On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote:
> On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote:
> > Hello,
> >
> > One thing that comes up a lot every LSF is the fact that we have no general
> > way
> > that we do performance testing. Every fs developer has a set of
On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote:
> Hello,
>
> One thing that comes up a lot every LSF is the fact that we have no general
> way
> that we do performance testing. Every fs developer has a set of scripts or
> things that they run with varying degrees of consistency,
On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote:
> Hello,
>
> One thing that comes up a lot every LSF is the fact that we have no general
> way
> that we do performance testing. Every fs developer has a set of scripts or
> things that they run with varying degrees of consistency,
Hello,
One thing that comes up a lot every LSF is the fact that we have no general way
that we do performance testing. Every fs developer has a set of scripts or
things that they run with varying degrees of consistency, but nothing central
that we all use. I for one am getting tired of finding
Hello,
One thing that comes up a lot every LSF is the fact that we have no general way
that we do performance testing. Every fs developer has a set of scripts or
things that they run with varying degrees of consistency, but nothing central
that we all use. I for one am getting tired of finding
Signed-of-by Alexandru Copot
Cc: Daniel Baluta
---
tools/testing/selftests/net/Makefile | 14 +++--
tools/testing/selftests/net/socket.c | 108 +--
2 files changed, 88 insertions(+), 34 deletions(-)
diff --git a/tools/testing/selftests/net/Makefile
Signed-of-by Alexandru Copot alex.miha...@gmail.com
Cc: Daniel Baluta dbal...@ixiacom.com
---
tools/testing/selftests/net/Makefile | 14 +++--
tools/testing/selftests/net/socket.c | 108 +--
2 files changed, 88 insertions(+), 34 deletions(-)
diff --git
Hi!
> For some time I had been working on this file system
> test framework.
> Now I have a implementation for the same and below is
> the explanation.
> Any comments are welcome.
>
> Introduction:
> The testing tools and benchmarks available around do not
> take into
> account the repair and
Hi!
For some time I had been working on this file system
test framework.
Now I have a implementation for the same and below is
the explanation.
Any comments are welcome.
Introduction:
The testing tools and benchmarks available around do not
take into
account the repair and recovery
On 4/23/07, Avishay Traeger <[EMAIL PROTECTED]> wrote:
On Mon, 2007-04-23 at 02:16 +0530, Karuna sagar K wrote:
You may want to check out the paper "EXPLODE: A Lightweight, General
System for Finding Serious Storage System Errors" from OSDI 2006 (if you
haven't already). The idea sounds very
On 4/23/07, Avishay Traeger [EMAIL PROTECTED] wrote:
On Mon, 2007-04-23 at 02:16 +0530, Karuna sagar K wrote:
snip
You may want to check out the paper EXPLODE: A Lightweight, General
System for Finding Serious Storage System Errors from OSDI 2006 (if you
haven't already). The idea sounds very
Avishay Traeger wrote:
On Mon, 2007-04-23 at 02:16 +0530, Karuna sagar K wrote:
For some time I had been working on this file system test framework.
Now I have a implementation for the same and below is the explanation.
Any comments are welcome.
You may want to check out the paper "EXPLODE:
On Mon, 2007-04-23 at 02:16 +0530, Karuna sagar K wrote:
> For some time I had been working on this file system test framework.
> Now I have a implementation for the same and below is the explanation.
> Any comments are welcome.
You may want to check out the paper "EXPLODE: A Lightweight,
On 4/23/07, Kalpak Shah <[EMAIL PROTECTED]> wrote:
On Mon, 2007-04-23 at 02:16 +0530, Karuna sagar K wrote:
.
The file system is looked upon as a set of blocks (more precisely
metadata blocks). We randomly choose from this set of blocks to
corrupt. Hence we would be able to overcome the
On Mon, 2007-04-23 at 02:16 +0530, Karuna sagar K wrote:
> Hi,
>
> For some time I had been working on this file system test framework.
> Now I have a implementation for the same and below is the explanation.
> Any comments are welcome.
>
> Introduction:
> The testing tools and benchmarks
On Mon, 2007-04-23 at 02:16 +0530, Karuna sagar K wrote:
Hi,
For some time I had been working on this file system test framework.
Now I have a implementation for the same and below is the explanation.
Any comments are welcome.
Introduction:
The testing tools and benchmarks available
On 4/23/07, Kalpak Shah [EMAIL PROTECTED] wrote:
On Mon, 2007-04-23 at 02:16 +0530, Karuna sagar K wrote:
.
The file system is looked upon as a set of blocks (more precisely
metadata blocks). We randomly choose from this set of blocks to
corrupt. Hence we would be able to overcome the
On Mon, 2007-04-23 at 02:16 +0530, Karuna sagar K wrote:
For some time I had been working on this file system test framework.
Now I have a implementation for the same and below is the explanation.
Any comments are welcome.
snip
You may want to check out the paper EXPLODE: A Lightweight,
Avishay Traeger wrote:
On Mon, 2007-04-23 at 02:16 +0530, Karuna sagar K wrote:
For some time I had been working on this file system test framework.
Now I have a implementation for the same and below is the explanation.
Any comments are welcome.
snip
You may want to check out the paper
Hi,
For some time I had been working on this file system test framework.
Now I have a implementation for the same and below is the explanation.
Any comments are welcome.
Introduction:
The testing tools and benchmarks available around do not take into
account the repair and recovery aspects of
Hi,
For some time I had been working on this file system test framework.
Now I have a implementation for the same and below is the explanation.
Any comments are welcome.
Introduction:
The testing tools and benchmarks available around do not take into
account the repair and recovery aspects of
Hi,
I am working on a testing framework for file systems focusing on
repair and recovery areas. Right now, I have been timing fsck and
trying to determine the effectiveness of fsck. The idea that I have is
below.
In abstract terms, I create a file system (ideal state), corrupt it,
run fsck
Hi,
I am working on a testing framework for file systems focusing on
repair and recovery areas. Right now, I have been timing fsck and
trying to determine the effectiveness of fsck. The idea that I have is
below.
In abstract terms, I create a file system (ideal state), corrupt it,
run fsck
90 matches
Mail list logo
