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
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
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 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
Am Donnerstag, 30. April 2015, 10:20:08 schrieb Dave Chinner:
> On Wed, Apr 29, 2015 at 09:05:26PM +0200, Mike Galbraith wrote:
> > Here's something that _might_ interest xfs folks.
> >
> > cd git (source repository of git itself)
> > make clean
> > echo 3 > /proc/sys/vm/drop_caches
> > time make
Am Donnerstag, 30. April 2015, 10:20:08 schrieb Dave Chinner:
On Wed, Apr 29, 2015 at 09:05:26PM +0200, Mike Galbraith wrote:
Here's something that _might_ interest xfs folks.
cd git (source repository of git itself)
make clean
echo 3 /proc/sys/vm/drop_caches
time make -j8 test
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 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 crystal
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 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 Tux3 still
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 factored out of
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 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, Daniel Phillips wrote:
Lovely sounding argument, but it is
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 do a
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
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 really
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
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, Daniel Phillips
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 forget
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 of media
On Wed, 2015-04-29 at 14:12 -0700, Daniel Phillips wrote:
> Btrfs appears to optimize tiny files by storing them in its big btree,
> the equivalent of our itree, and Tux3 doesn't do that yet, so we are a
> bit hobbled for a make load.
That's not a build load, it's a git load. btrfs beat all
On Thu, 2015-04-30 at 10:20 +1000, Dave Chinner wrote:
> IOWS, XFS just hates your disk. Spend $50 and buy a cheap SSD and
> the problem goes away. :)
I'd love to. Too bad sorry sack of sh*t MB manufacturer only applied
_connectors_ to 4 of 6 available ports, and they're all in use :)
>
>
1 - 100 of 110 matches
Mail list logo
