Am Mittwoch, 13. Mai 2015, 13:38:24 schrieb Daniel Phillips:
> On Wednesday, May 13, 2015 1:25:38 PM PDT, Martin Steigerwald wrote:
> > Am Mittwoch, 13. Mai 2015, 12:37:41 schrieb Daniel Phillips:
> >> On 05/13/2015 12:09 PM, Martin Steigerwald wrote: ...
> >
> > Daniel, if you want to change the
On Wednesday, May 13, 2015 1:25:38 PM PDT, Martin Steigerwald wrote:
Am Mittwoch, 13. Mai 2015, 12:37:41 schrieb Daniel Phillips:
On 05/13/2015 12:09 PM, Martin Steigerwald wrote: ...
Daniel, if you want to change the process of patch review and
inclusion into
the kernel, model an example
Am Mittwoch, 13. Mai 2015, 12:37:41 schrieb Daniel Phillips:
> On 05/13/2015 12:09 PM, Martin Steigerwald wrote:
> > Daniel, what are you trying to achieve here?
> >
> > I thought you wanted to create interest for your filesystem and
> > acceptance for merging it.
> >
> > What I see you are
On Wednesday, May 13, 2015 1:02:34 PM PDT, Jeremy Allison wrote:
On Wed, May 13, 2015 at 12:37:41PM -0700, Daniel Phillips wrote:
On 05/13/2015 12:09 PM, Martin Steigerwald wrote:
...
Daniel, please listen to Martin. He speaks a fundamental truth
here.
As you know, I am also interested in
On Wed, May 13, 2015 at 12:37:41PM -0700, Daniel Phillips wrote:
> On 05/13/2015 12:09 PM, Martin Steigerwald wrote:
>
> > "Assume good faith" can help here. No amount of accusing people of bad
> > intention will change them. The only thing you have the power to change is
> > your approach. You
On 05/13/2015 12:09 PM, Martin Steigerwald wrote:
> Daniel, what are you trying to achieve here?
>
> I thought you wanted to create interest for your filesystem and acceptance
> for merging it.
>
> What I see you are actually creating tough is something different.
>
> Is what you see after you
Am Dienstag, 12. Mai 2015, 18:26:28 schrieb Daniel Phillips:
> On 05/12/2015 03:35 PM, David Lang wrote:
> > On Tue, 12 May 2015, Daniel Phillips wrote:
> >> On 05/12/2015 02:30 PM, David Lang wrote:
> >>> You need to get out of the mindset that Ted and Dave are Enemies that
> >>> you need to
On 05/13/2015 06:08 AM, Mike Galbraith wrote:
> On Wed, 2015-05-13 at 04:31 -0700, Daniel Phillips wrote:
>> Third possibility: build from our repository, as Mike did.
>
> Sorry about that folks. I've lost all interest, it won't happen again.
Thanks for your valuable contribution. Now we are
On Wed, 2015-05-13 at 04:31 -0700, Daniel Phillips wrote:
> Third possibility: build from our repository, as Mike did.
Sorry about that folks. I've lost all interest, it won't happen again.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On 05/13/2015 04:31 AM, Daniel Phillips wrote:
Let me be the first to catch that arithmetic error
> Let's say our delta size is 400MB (typical under load) and we leave
> a "nice big gap" of 112 MB after flushing each one. Let's say we do
> two thousand of those before deciding that we have
On 05/13/2015 12:25 AM, Pavel Machek wrote:
> On Mon 2015-05-11 16:53:10, Daniel Phillips wrote:
>> Hi Pavel,
>>
>> On 05/11/2015 03:12 PM, Pavel Machek wrote:
> It is a fact of life that when you change one aspect of an intimately
> interconnected system,
> something else will change
On Mon 2015-05-11 16:53:10, Daniel Phillips wrote:
> Hi Pavel,
>
> On 05/11/2015 03:12 PM, Pavel Machek wrote:
> >>> It is a fact of life that when you change one aspect of an intimately
> >>> interconnected system,
> >>> something else will change as well. You have naive/nonexistent free space
On Tue 2015-05-12 13:54:58, Daniel Phillips wrote:
> On 05/12/2015 11:39 AM, David Lang wrote:
> > On Mon, 11 May 2015, Daniel Phillips wrote:
> >>> ...it's the mm and core kernel developers that need to
> >>> review and accept that code *before* we can consider merging tux3.
> >>
> >> Please do
On 05/13/2015 12:25 AM, Pavel Machek wrote:
On Mon 2015-05-11 16:53:10, Daniel Phillips wrote:
Hi Pavel,
On 05/11/2015 03:12 PM, Pavel Machek wrote:
It is a fact of life that when you change one aspect of an intimately
interconnected system,
something else will change as well. You have
On 05/13/2015 04:31 AM, Daniel Phillips wrote:
Let me be the first to catch that arithmetic error
Let's say our delta size is 400MB (typical under load) and we leave
a nice big gap of 112 MB after flushing each one. Let's say we do
two thousand of those before deciding that we have enough
On Wed, 2015-05-13 at 04:31 -0700, Daniel Phillips wrote:
Third possibility: build from our repository, as Mike did.
Sorry about that folks. I've lost all interest, it won't happen again.
-Mike
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On 05/13/2015 06:08 AM, Mike Galbraith wrote:
On Wed, 2015-05-13 at 04:31 -0700, Daniel Phillips wrote:
Third possibility: build from our repository, as Mike did.
Sorry about that folks. I've lost all interest, it won't happen again.
Thanks for your valuable contribution. Now we are seeing
Am Dienstag, 12. Mai 2015, 18:26:28 schrieb Daniel Phillips:
On 05/12/2015 03:35 PM, David Lang wrote:
On Tue, 12 May 2015, Daniel Phillips wrote:
On 05/12/2015 02:30 PM, David Lang wrote:
You need to get out of the mindset that Ted and Dave are Enemies that
you need to overcome, they are
On Wednesday, May 13, 2015 1:25:38 PM PDT, Martin Steigerwald wrote:
Am Mittwoch, 13. Mai 2015, 12:37:41 schrieb Daniel Phillips:
On 05/13/2015 12:09 PM, Martin Steigerwald wrote: ...
Daniel, if you want to change the process of patch review and
inclusion into
the kernel, model an example
On 05/13/2015 12:09 PM, Martin Steigerwald wrote:
Daniel, what are you trying to achieve here?
I thought you wanted to create interest for your filesystem and acceptance
for merging it.
What I see you are actually creating tough is something different.
Is what you see after you send
Am Mittwoch, 13. Mai 2015, 13:38:24 schrieb Daniel Phillips:
On Wednesday, May 13, 2015 1:25:38 PM PDT, Martin Steigerwald wrote:
Am Mittwoch, 13. Mai 2015, 12:37:41 schrieb Daniel Phillips:
On 05/13/2015 12:09 PM, Martin Steigerwald wrote: ...
Daniel, if you want to change the process
On Wed, May 13, 2015 at 12:37:41PM -0700, Daniel Phillips wrote:
On 05/13/2015 12:09 PM, Martin Steigerwald wrote:
Assume good faith can help here. No amount of accusing people of bad
intention will change them. The only thing you have the power to change is
your approach. You
Am Mittwoch, 13. Mai 2015, 12:37:41 schrieb Daniel Phillips:
On 05/13/2015 12:09 PM, Martin Steigerwald wrote:
Daniel, what are you trying to achieve here?
I thought you wanted to create interest for your filesystem and
acceptance for merging it.
What I see you are actually creating
On Wednesday, May 13, 2015 1:02:34 PM PDT, Jeremy Allison wrote:
On Wed, May 13, 2015 at 12:37:41PM -0700, Daniel Phillips wrote:
On 05/13/2015 12:09 PM, Martin Steigerwald wrote:
...
Daniel, please listen to Martin. He speaks a fundamental truth
here.
As you know, I am also interested in
On Mon 2015-05-11 16:53:10, Daniel Phillips wrote:
Hi Pavel,
On 05/11/2015 03:12 PM, Pavel Machek wrote:
It is a fact of life that when you change one aspect of an intimately
interconnected system,
something else will change as well. You have naive/nonexistent free space
management
On Tue 2015-05-12 13:54:58, Daniel Phillips wrote:
On 05/12/2015 11:39 AM, David Lang wrote:
On Mon, 11 May 2015, Daniel Phillips wrote:
...it's the mm and core kernel developers that need to
review and accept that code *before* we can consider merging tux3.
Please do not say we when
On 05/12/2015 03:35 PM, David Lang wrote:
> On Tue, 12 May 2015, Daniel Phillips wrote:
>> On 05/12/2015 02:30 PM, David Lang wrote:
>>> You need to get out of the mindset that Ted and Dave are Enemies that you
>>> need to overcome, they are
>>> friendly competitors, not Enemies.
>>
>> You are
On 05/12/2015 02:30 PM, David Lang wrote:
> On Tue, 12 May 2015, Daniel Phillips wrote:
>> Phoronix published a headline that identifies Dave Chinner as
>> someone who takes shots at other projects. Seems pretty much on
>> the money to me, and it ought to be obvious why he does it.
>
> Phoronix
On Tue, May 12, 2015 at 03:35:43PM -0700, David Lang wrote:
>
> I happen to think that it's correct. It's not that Ext4 isn't tested, but
> that people's expectations of how much it's been tested, and at what scale
> don't match the reality.
Ext4 is used at Google, on a very large number of
On Tue, 12 May 2015, Daniel Phillips wrote:
On 05/12/2015 02:30 PM, David Lang wrote:
On Tue, 12 May 2015, Daniel Phillips wrote:
Phoronix published a headline that identifies Dave Chinner as
someone who takes shots at other projects. Seems pretty much on
the money to me, and it ought to be
On 05/12/2015 02:30 PM, David Lang wrote:
> On Tue, 12 May 2015, Daniel Phillips wrote:
>> Phoronix published a headline that identifies Dave Chinner as
>> someone who takes shots at other projects. Seems pretty much on
>> the money to me, and it ought to be obvious why he does it.
>
> Phoronix
On 12.05.2015 22:54, Daniel Phillips wrote:
On 05/12/2015 11:39 AM, David Lang wrote:
On Mon, 11 May 2015, Daniel Phillips wrote:
...it's the mm and core kernel developers that need to
review and accept that code *before* we can consider merging tux3.
Please do not say "we" when you know that
On Tue, 12 May 2015, Daniel Phillips wrote:
On 05/12/2015 11:39 AM, David Lang wrote:
On Mon, 11 May 2015, Daniel Phillips wrote:
...it's the mm and core kernel developers that need to
review and accept that code *before* we can consider merging tux3.
Please do not say "we" when you know
On 05/12/2015 11:39 AM, David Lang wrote:
> On Mon, 11 May 2015, Daniel Phillips wrote:
>>> ...it's the mm and core kernel developers that need to
>>> review and accept that code *before* we can consider merging tux3.
>>
>> Please do not say "we" when you know that I am just as much a "we"
>> as
On Mon, 11 May 2015, Daniel Phillips wrote:
On Monday, May 11, 2015 10:38:42 PM PDT, Dave Chinner wrote:
I think Ted and I are on the same page here. "Competitive
benchmarks" only matter to the people who are trying to sell
something. You're trying to sell Tux3, but
By "same page", do
Tux3 Report: How fast can we fail?
Tux3 now has a preliminary out of space handling algorithm. This might
sound like a small thing, but in fact handling out of space reliably
and efficiently is really hard, especially for Tux3. We developed an
original solution with unusually low overhead in the
Am 12.05.2015 06:36, schrieb Daniel Phillips:
Hi David,
On 05/11/2015 05:12 PM, David Lang wrote:
On Mon, 11 May 2015, Daniel Phillips wrote:
On 05/11/2015 03:12 PM, Pavel Machek wrote:
It is a fact of life that when you change one aspect of an intimately
interconnected system,
something
Daniel Phillips wrote:
On 05/12/2015 02:03 AM, Pavel Machek wrote:
I'd call system with 65 tasks doing heavy fsync load at the some time
"embarrassingly misconfigured" :-). It is nice if your filesystem can
stay fast in that case, but...
Well, Tux3 wins the fsync race now whether it is 1
On 05/12/2015 02:03 AM, Pavel Machek wrote:
> On Mon 2015-05-11 19:34:34, Daniel Phillips wrote:
>> On 05/11/2015 04:17 PM, Theodore Ts'o wrote:
>>> and another way that people
>>> doing competitive benchmarking can screw up and produce misleading
>>> numbers.
>>
>> If you think we screwed up or
On Mon 2015-05-11 19:34:34, Daniel Phillips wrote:
>
>
> On 05/11/2015 04:17 PM, Theodore Ts'o wrote:
> > On Tue, May 12, 2015 at 12:12:23AM +0200, Pavel Machek wrote:
> >> Umm, are you sure. If "some areas of disk are faster than others" is
> >> still true on todays harddrives, the gaps will
On Monday, May 11, 2015 10:38:42 PM PDT, Dave Chinner wrote:
> I think Ted and I are on the same page here. "Competitive
> benchmarks" only matter to the people who are trying to sell
> something. You're trying to sell Tux3, but
By "same page", do you mean "transparently obvious about
On Monday, May 11, 2015 10:38:42 PM PDT, Dave Chinner wrote:
I think Ted and I are on the same page here. Competitive
benchmarks only matter to the people who are trying to sell
something. You're trying to sell Tux3, but
By same page, do you mean transparently obvious about
obstructing
Am 12.05.2015 06:36, schrieb Daniel Phillips:
Hi David,
On 05/11/2015 05:12 PM, David Lang wrote:
On Mon, 11 May 2015, Daniel Phillips wrote:
On 05/11/2015 03:12 PM, Pavel Machek wrote:
It is a fact of life that when you change one aspect of an intimately
interconnected system,
something
Tux3 Report: How fast can we fail?
Tux3 now has a preliminary out of space handling algorithm. This might
sound like a small thing, but in fact handling out of space reliably
and efficiently is really hard, especially for Tux3. We developed an
original solution with unusually low overhead in the
On Mon, 11 May 2015, Daniel Phillips wrote:
On Monday, May 11, 2015 10:38:42 PM PDT, Dave Chinner wrote:
I think Ted and I are on the same page here. Competitive
benchmarks only matter to the people who are trying to sell
something. You're trying to sell Tux3, but
By same page, do you
On Tue, 12 May 2015, Daniel Phillips wrote:
On 05/12/2015 11:39 AM, David Lang wrote:
On Mon, 11 May 2015, Daniel Phillips wrote:
...it's the mm and core kernel developers that need to
review and accept that code *before* we can consider merging tux3.
Please do not say we when you know that
On 12.05.2015 22:54, Daniel Phillips wrote:
On 05/12/2015 11:39 AM, David Lang wrote:
On Mon, 11 May 2015, Daniel Phillips wrote:
...it's the mm and core kernel developers that need to
review and accept that code *before* we can consider merging tux3.
Please do not say we when you know that I
On 05/12/2015 11:39 AM, David Lang wrote:
On Mon, 11 May 2015, Daniel Phillips wrote:
...it's the mm and core kernel developers that need to
review and accept that code *before* we can consider merging tux3.
Please do not say we when you know that I am just as much a we
as you are. Merging
On 05/12/2015 03:35 PM, David Lang wrote:
On Tue, 12 May 2015, Daniel Phillips wrote:
On 05/12/2015 02:30 PM, David Lang wrote:
You need to get out of the mindset that Ted and Dave are Enemies that you
need to overcome, they are
friendly competitors, not Enemies.
You are wrong about Dave
On 05/12/2015 02:30 PM, David Lang wrote:
On Tue, 12 May 2015, Daniel Phillips wrote:
Phoronix published a headline that identifies Dave Chinner as
someone who takes shots at other projects. Seems pretty much on
the money to me, and it ought to be obvious why he does it.
Phoronix turns any
On Tue, 12 May 2015, Daniel Phillips wrote:
On 05/12/2015 02:30 PM, David Lang wrote:
On Tue, 12 May 2015, Daniel Phillips wrote:
Phoronix published a headline that identifies Dave Chinner as
someone who takes shots at other projects. Seems pretty much on
the money to me, and it ought to be
On 05/12/2015 02:30 PM, David Lang wrote:
On Tue, 12 May 2015, Daniel Phillips wrote:
Phoronix published a headline that identifies Dave Chinner as
someone who takes shots at other projects. Seems pretty much on
the money to me, and it ought to be obvious why he does it.
Phoronix turns any
On Tue, May 12, 2015 at 03:35:43PM -0700, David Lang wrote:
I happen to think that it's correct. It's not that Ext4 isn't tested, but
that people's expectations of how much it's been tested, and at what scale
don't match the reality.
Ext4 is used at Google, on a very large number of disks.
On Mon 2015-05-11 19:34:34, Daniel Phillips wrote:
On 05/11/2015 04:17 PM, Theodore Ts'o wrote:
On Tue, May 12, 2015 at 12:12:23AM +0200, Pavel Machek wrote:
Umm, are you sure. If some areas of disk are faster than others is
still true on todays harddrives, the gaps will decrease the
Daniel Phillips wrote:
On 05/12/2015 02:03 AM, Pavel Machek wrote:
I'd call system with 65 tasks doing heavy fsync load at the some time
embarrassingly misconfigured :-). It is nice if your filesystem can
stay fast in that case, but...
Well, Tux3 wins the fsync race now whether it is 1 task,
On 05/12/2015 02:03 AM, Pavel Machek wrote:
On Mon 2015-05-11 19:34:34, Daniel Phillips wrote:
On 05/11/2015 04:17 PM, Theodore Ts'o wrote:
and another way that people
doing competitive benchmarking can screw up and produce misleading
numbers.
If you think we screwed up or produced
On Mon, May 11, 2015 at 07:34:34PM -0700, Daniel Phillips wrote:
> Anyway, everybody but you loves competitive benchmarks, that is why I
I think Ted and I are on the same page here. "Competitive
benchmarks" only matter to the people who are trying to sell
something. You're trying to sell Tux3,
Hi David,
On 05/11/2015 05:12 PM, David Lang wrote:
> On Mon, 11 May 2015, Daniel Phillips wrote:
>
>> On 05/11/2015 03:12 PM, Pavel Machek wrote:
> It is a fact of life that when you change one aspect of an intimately
> interconnected system,
> something else will change as well.
On 05/11/2015 04:17 PM, Theodore Ts'o wrote:
> On Tue, May 12, 2015 at 12:12:23AM +0200, Pavel Machek wrote:
>> Umm, are you sure. If "some areas of disk are faster than others" is
>> still true on todays harddrives, the gaps will decrease the
>> performance (as you'll "use up" the fast areas
On Mon, 11 May 2015, Daniel Phillips wrote:
On 05/11/2015 03:12 PM, Pavel Machek wrote:
It is a fact of life that when you change one aspect of an intimately
interconnected system,
something else will change as well. You have naive/nonexistent free space
management now; when you
design
Hi Pavel,
On 05/11/2015 03:12 PM, Pavel Machek wrote:
>>> It is a fact of life that when you change one aspect of an intimately
>>> interconnected system,
>>> something else will change as well. You have naive/nonexistent free space
>>> management now; when you
>>> design something workable
On Tue, May 12, 2015 at 12:12:23AM +0200, Pavel Machek wrote:
> Umm, are you sure. If "some areas of disk are faster than others" is
> still true on todays harddrives, the gaps will decrease the
> performance (as you'll "use up" the fast areas more quickly).
It's still true. The difference
Hi!
> > It is a fact of life that when you change one aspect of an intimately
> > interconnected system,
> > something else will change as well. You have naive/nonexistent free space
> > management now; when you
> > design something workable there it is going to impact everything else
> >
Hi!
It is a fact of life that when you change one aspect of an intimately
interconnected system,
something else will change as well. You have naive/nonexistent free space
management now; when you
design something workable there it is going to impact everything else
you've already
On Mon, 11 May 2015, Daniel Phillips wrote:
On 05/11/2015 03:12 PM, Pavel Machek wrote:
It is a fact of life that when you change one aspect of an intimately
interconnected system,
something else will change as well. You have naive/nonexistent free space
management now; when you
design
Hi Pavel,
On 05/11/2015 03:12 PM, Pavel Machek wrote:
It is a fact of life that when you change one aspect of an intimately
interconnected system,
something else will change as well. You have naive/nonexistent free space
management now; when you
design something workable there it is going
On Tue, May 12, 2015 at 12:12:23AM +0200, Pavel Machek wrote:
Umm, are you sure. If some areas of disk are faster than others is
still true on todays harddrives, the gaps will decrease the
performance (as you'll use up the fast areas more quickly).
It's still true. The difference between O.D.
Hi David,
On 05/11/2015 05:12 PM, David Lang wrote:
On Mon, 11 May 2015, Daniel Phillips wrote:
On 05/11/2015 03:12 PM, Pavel Machek wrote:
It is a fact of life that when you change one aspect of an intimately
interconnected system,
something else will change as well. You have
On Mon, May 11, 2015 at 07:34:34PM -0700, Daniel Phillips wrote:
Anyway, everybody but you loves competitive benchmarks, that is why I
I think Ted and I are on the same page here. Competitive
benchmarks only matter to the people who are trying to sell
something. You're trying to sell Tux3,
On 05/11/2015 04:17 PM, Theodore Ts'o wrote:
On Tue, May 12, 2015 at 12:12:23AM +0200, Pavel Machek wrote:
Umm, are you sure. If some areas of disk are faster than others is
still true on todays harddrives, the gaps will decrease the
performance (as you'll use up the fast areas more
On 2nd of May 2015 18:30, Richard Weinberger wrote:
On Sat, May 2, 2015 at 6:00 PM, Christian Stroetmann
wrote:
On the 2nd of May 2015 12:26, Daniel Phillips wrote:
Aloha everybody
On Friday, May 1, 2015 6:07:48 PM PDT, David Lang wrote:
On Fri, 1 May 2015, Daniel Phillips wrote:
On
On Sat, May 2, 2015 at 6:00 PM, Christian Stroetmann
wrote:
> On the 2nd of May 2015 12:26, Daniel Phillips wrote:
>
> Aloha everybody
>
>> On Friday, May 1, 2015 6:07:48 PM PDT, David Lang wrote:
>>>
>>> On Fri, 1 May 2015, Daniel Phillips wrote:
On Friday, May 1, 2015 8:38:55 AM PDT,
On the 2nd of May 2015 12:26, Daniel Phillips wrote:
Aloha everybody
On Friday, May 1, 2015 6:07:48 PM PDT, David Lang wrote:
On Fri, 1 May 2015, Daniel Phillips wrote:
On Friday, May 1, 2015 8:38:55 AM PDT, Dave Chinner wrote:
Well, yes - I never claimed XFS is a general purpose
On Friday, May 1, 2015 6:07:48 PM PDT, David Lang wrote:
On Fri, 1 May 2015, Daniel Phillips wrote:
On Friday, May 1, 2015 8:38:55 AM PDT, Dave Chinner wrote:
Well, yes - I never claimed XFS is a general purpose filesystem. It
is a high performance filesystem. Is is also becoming more
On Friday, May 1, 2015 6:07:48 PM PDT, David Lang wrote:
On Fri, 1 May 2015, Daniel Phillips wrote:
On Friday, May 1, 2015 8:38:55 AM PDT, Dave Chinner wrote:
Well, yes - I never claimed XFS is a general purpose filesystem. It
is a high performance filesystem. Is is also becoming more
On the 2nd of May 2015 12:26, Daniel Phillips wrote:
Aloha everybody
On Friday, May 1, 2015 6:07:48 PM PDT, David Lang wrote:
On Fri, 1 May 2015, Daniel Phillips wrote:
On Friday, May 1, 2015 8:38:55 AM PDT, Dave Chinner wrote:
Well, yes - I never claimed XFS is a general purpose
On Sat, May 2, 2015 at 6:00 PM, Christian Stroetmann
stroetm...@ontolab.com wrote:
On the 2nd of May 2015 12:26, Daniel Phillips wrote:
Aloha everybody
On Friday, May 1, 2015 6:07:48 PM PDT, David Lang wrote:
On Fri, 1 May 2015, Daniel Phillips wrote:
On Friday, May 1, 2015 8:38:55 AM
On 2nd of May 2015 18:30, Richard Weinberger wrote:
On Sat, May 2, 2015 at 6:00 PM, Christian Stroetmann
stroetm...@ontolab.com wrote:
On the 2nd of May 2015 12:26, Daniel Phillips wrote:
Aloha everybody
On Friday, May 1, 2015 6:07:48 PM PDT, David Lang wrote:
On Fri, 1 May 2015, Daniel
On Fri, 1 May 2015, Daniel Phillips wrote:
On Friday, May 1, 2015 8:38:55 AM PDT, Dave Chinner wrote:
Well, yes - I never claimed XFS is a general purpose filesystem. It
is a high performance filesystem. Is is also becoming more relevant
to general purpose systems as low cost storage gains
On Friday, May 1, 2015 8:38:55 AM PDT, Dave Chinner wrote:
>
> Well, yes - I never claimed XFS is a general purpose filesystem. It
> is a high performance filesystem. Is is also becoming more relevant
> to general purpose systems as low cost storage gains capabilities
> that used to be considered
On Thu, Apr 30, 2015 at 03:28:13AM -0700, Daniel Phillips wrote:
> On Wednesday, April 29, 2015 6:46:16 PM PDT, Dave Chinner wrote:
> >>I measured fsync performance using a 7200 RPM disk as a virtual
> >>drive under KVM, configured with cache=none so that asynchronous
> >>writes are cached and
On Friday, May 1, 2015 8:38:55 AM PDT, Dave Chinner wrote:
Well, yes - I never claimed XFS is a general purpose filesystem. It
is a high performance filesystem. Is is also becoming more relevant
to general purpose systems as low cost storage gains capabilities
that used to be considered the
On Fri, 1 May 2015, Daniel Phillips wrote:
On Friday, May 1, 2015 8:38:55 AM PDT, Dave Chinner wrote:
Well, yes - I never claimed XFS is a general purpose filesystem. It
is a high performance filesystem. Is is also becoming more relevant
to general purpose systems as low cost storage gains
On Thu, Apr 30, 2015 at 03:28:13AM -0700, Daniel Phillips wrote:
On Wednesday, April 29, 2015 6:46:16 PM PDT, Dave Chinner wrote:
I measured fsync performance using a 7200 RPM disk as a virtual
drive under KVM, configured with cache=none so that asynchronous
writes are cached and synchronous
On the 30th of April 2015 17:14, Daniel Phillips wrote:
Hallo hardcore coders
On 04/30/2015 07:28 AM, Howard Chu wrote:
Daniel Phillips wrote:
On 04/30/2015 06:48 AM, Mike Galbraith wrote:
On Thu, 2015-04-30 at 05:58 -0700, Daniel Phillips wrote:
On Thursday, April 30, 2015 5:07:21 AM
Am Donnerstag, 30. April 2015, 10:57:10 schrieb Theodore Ts'o:
> One of the problems is that it's *hard* to get good benchmarking
> numbers that take into account file system aging and measure how well
> the free space has been fragmented over time. Most of the benchmark
> results that I've seen
Daniel Phillips wrote:
On 04/30/2015 07:28 AM, Howard Chu wrote:
You're reading into it what isn't there. Spreading over the disk isn't (just)
about avoiding
fragmentation - it's about delivering consistent and predictable latency. It is
undeniable that if
you start by only allocating from
Hi Ted,
On 04/30/2015 07:57 AM, Theodore Ts'o wrote:
> This is one of the reasons why I find head-to-head "competitions"
> between file systems to be not very helpful for anything other than
> benchmarketing. It's almost certain that the benchmark won't be
> "fair" in some way, and it doesn't
On 04/30/2015 07:33 AM, Mike Galbraith wrote:
> Well ok, let's forget bad blood, straw men... and answering my question
> too I suppose. Not having any sexy IO gizmos in my little desktop box,
> I don't care deeply which stomps the other flat on beastly boxen.
I'm with you, especially the
On 04/30/2015 07:28 AM, Howard Chu wrote:
> Daniel Phillips wrote:
>>
>>
>> On 04/30/2015 06:48 AM, Mike Galbraith wrote:
>>> On Thu, 2015-04-30 at 05:58 -0700, Daniel Phillips wrote:
On Thursday, April 30, 2015 5:07:21 AM PDT, Mike Galbraith wrote:
> On Thu, 2015-04-30 at 04:14 -0700,
On Thu, Apr 30, 2015 at 11:00:05AM +0200, Martin Steigerwald wrote:
> > IOWS, XFS just hates your disk. Spend $50 and buy a cheap SSD and
> > the problem goes away. :)
>
> I am quite surprised that a traditional filesystem that was created in the
> age of rotating media does not like this kind
Daniel Phillips wrote:
On 04/30/2015 06:48 AM, Mike Galbraith wrote:
On Thu, 2015-04-30 at 05:58 -0700, Daniel Phillips wrote:
On Thursday, April 30, 2015 5:07:21 AM PDT, Mike Galbraith wrote:
On Thu, 2015-04-30 at 04:14 -0700, Daniel Phillips wrote:
Lovely sounding argument, but it is
On Thu, 2015-04-30 at 07:07 -0700, Daniel Phillips wrote:
>
> On 04/30/2015 06:48 AM, Mike Galbraith wrote:
> > On Thu, 2015-04-30 at 05:58 -0700, Daniel Phillips wrote:
> >> On Thursday, April 30, 2015 5:07:21 AM PDT, Mike Galbraith wrote:
> >>> On Thu, 2015-04-30 at 04:14 -0700, Daniel Phillips
On 04/30/2015 06:48 AM, Mike Galbraith wrote:
> On Thu, 2015-04-30 at 05:58 -0700, Daniel Phillips wrote:
>> On Thursday, April 30, 2015 5:07:21 AM PDT, Mike Galbraith wrote:
>>> On Thu, 2015-04-30 at 04:14 -0700, Daniel Phillips wrote:
>>>
Lovely sounding argument, but it is wrong because
On Thu, 2015-04-30 at 05:58 -0700, Daniel Phillips wrote:
> On Thursday, April 30, 2015 5:07:21 AM PDT, Mike Galbraith wrote:
> > On Thu, 2015-04-30 at 04:14 -0700, Daniel Phillips wrote:
> >
> >> Lovely sounding argument, but it is wrong because Tux3 still beats XFS
> >> even with seek time
On Thursday, April 30, 2015 5:07:21 AM PDT, Mike Galbraith wrote:
On Thu, 2015-04-30 at 04:14 -0700, Daniel Phillips wrote:
Lovely sounding argument, but it is wrong because Tux3 still beats XFS
even with seek time factored out of the equation.
Hm. Do you have big-storage comparison numbers
On Thu, 2015-04-30 at 04:14 -0700, Daniel Phillips wrote:
> Lovely sounding argument, but it is wrong because Tux3 still beats XFS
> even with seek time factored out of the equation.
Hm. Do you have big-storage comparison numbers to back that? I'm no
storage guy (waiting for holographic
On Wednesday, April 29, 2015 5:20:08 PM PDT, Dave Chinner wrote:
It's easy to be fast on empty filesystems. XFS does not aim to be
fast in such situations - it aims to have consistent performance
across the life of the filesystem.
In this case, ext4, btrfs and tux3 have optimal allocation
On Wednesday, April 29, 2015 8:50:57 PM PDT, Mike Galbraith wrote:
On Wed, 2015-04-29 at 13:40 -0700, Daniel Phillips wrote:
That order of magnitude latency difference is striking. It sounds
good, but what does it mean? I see a smaller difference here, maybe
because of running under KVM.
On Wednesday, April 29, 2015 6:46:16 PM PDT, Dave Chinner wrote:
I measured fsync performance using a 7200 RPM disk as a virtual
drive under KVM, configured with cache=none so that asynchronous
writes are cached and synchronous writes translate into direct
writes to the block device.
Yup, a
1 - 100 of 156 matches
Mail list logo