On Tue, Dec 11, 2012 at 12:16:03PM +, Steven Whitehouse wrote:
> On Mon, 2012-12-10 at 13:20 -0500, Theodore Ts'o wrote:
> > A sentence or two got chopped out during an editing pass. Let me try
> > that again so it's a bit clearer what I was trying to say
> >
> > Sure, but if the block
Hi,
On Mon, 2012-12-10 at 13:20 -0500, Theodore Ts'o wrote:
> A sentence or two got chopped out during an editing pass. Let me try
> that again so it's a bit clearer what I was trying to say
>
> Sure, but if the block device supports WRITE_SAME or persistent
> discard, then presumably
Hi,
On Mon, 2012-12-10 at 13:20 -0500, Theodore Ts'o wrote:
A sentence or two got chopped out during an editing pass. Let me try
that again so it's a bit clearer what I was trying to say
Sure, but if the block device supports WRITE_SAME or persistent
discard, then presumably
On Tue, Dec 11, 2012 at 12:16:03PM +, Steven Whitehouse wrote:
On Mon, 2012-12-10 at 13:20 -0500, Theodore Ts'o wrote:
A sentence or two got chopped out during an editing pass. Let me try
that again so it's a bit clearer what I was trying to say
Sure, but if the block device
On Mon, Dec 10, 2012 at 12:37:39PM -0500, Theodore Ts'o wrote:
> On Sat, Dec 08, 2012 at 11:17:05AM +1100, Dave Chinner wrote:
> > I wouldn't recommend XFS_IOC_ALLOCSP as a user-friendly interface.
> > The concept, however, implemented by a new fallocate()
> > flag (say FALLOC_FL_WRITE_ZEROS) so
On 12/10/2012 12:37 PM, Theodore Ts'o wrote:
On Sat, Dec 08, 2012 at 11:17:05AM +1100, Dave Chinner wrote:
I wouldn't recommend XFS_IOC_ALLOCSP as a user-friendly interface.
The concept, however, implemented by a new fallocate()
flag (say FALLOC_FL_WRITE_ZEROS) so that the filesystem knows that
A sentence or two got chopped out during an editing pass. Let me try
that again so it's a bit clearer what I was trying to say
Sure, but if the block device supports WRITE_SAME or persistent
discard, then presumably fallocate() should do this automatically all
the time, and not require a
On Mon, Dec 10, 2012 at 06:05:59PM +, Steven Whitehouse wrote:
>
> If the block device can zero out blocks more efficiently than just
> writing zeros (i.e. via sb_issue_zeroout()) then this could be faster.
> In fact GFS2 already zeros out fallocate()d extents in this way because
> it has no
Hi,
On Mon, 2012-12-10 at 12:37 -0500, Theodore Ts'o wrote:
> On Sat, Dec 08, 2012 at 11:17:05AM +1100, Dave Chinner wrote:
> > I wouldn't recommend XFS_IOC_ALLOCSP as a user-friendly interface.
> > The concept, however, implemented by a new fallocate()
> > flag (say FALLOC_FL_WRITE_ZEROS) so
On Sat, Dec 08, 2012 at 11:17:05AM +1100, Dave Chinner wrote:
> I wouldn't recommend XFS_IOC_ALLOCSP as a user-friendly interface.
> The concept, however, implemented by a new fallocate()
> flag (say FALLOC_FL_WRITE_ZEROS) so that the filesystem knows that
> the application considers unwritten
On Fri, Dec 07, 2012 at 06:39:49PM -0700, Chris Mason wrote:
> On Fri, Dec 07, 2012 at 05:17:05PM -0700, Dave Chinner wrote:
> > On Fri, Dec 07, 2012 at 02:03:06PM -0500, Chris Mason wrote:
> > > On a single flash drive doing random 4K writes, xfs does 950MB/s into
> > > regular extents but only
On Fri, Dec 07, 2012 at 06:39:49PM -0700, Chris Mason wrote:
On Fri, Dec 07, 2012 at 05:17:05PM -0700, Dave Chinner wrote:
On Fri, Dec 07, 2012 at 02:03:06PM -0500, Chris Mason wrote:
On a single flash drive doing random 4K writes, xfs does 950MB/s into
regular extents but only 400MB/s
On Sat, Dec 08, 2012 at 11:17:05AM +1100, Dave Chinner wrote:
I wouldn't recommend XFS_IOC_ALLOCSP as a user-friendly interface.
The concept, however, implemented by a new fallocate()
flag (say FALLOC_FL_WRITE_ZEROS) so that the filesystem knows that
the application considers unwritten extents
Hi,
On Mon, 2012-12-10 at 12:37 -0500, Theodore Ts'o wrote:
On Sat, Dec 08, 2012 at 11:17:05AM +1100, Dave Chinner wrote:
I wouldn't recommend XFS_IOC_ALLOCSP as a user-friendly interface.
The concept, however, implemented by a new fallocate()
flag (say FALLOC_FL_WRITE_ZEROS) so that the
On Mon, Dec 10, 2012 at 06:05:59PM +, Steven Whitehouse wrote:
If the block device can zero out blocks more efficiently than just
writing zeros (i.e. via sb_issue_zeroout()) then this could be faster.
In fact GFS2 already zeros out fallocate()d extents in this way because
it has no way
A sentence or two got chopped out during an editing pass. Let me try
that again so it's a bit clearer what I was trying to say
Sure, but if the block device supports WRITE_SAME or persistent
discard, then presumably fallocate() should do this automatically all
the time, and not require a
On 12/10/2012 12:37 PM, Theodore Ts'o wrote:
On Sat, Dec 08, 2012 at 11:17:05AM +1100, Dave Chinner wrote:
I wouldn't recommend XFS_IOC_ALLOCSP as a user-friendly interface.
The concept, however, implemented by a new fallocate()
flag (say FALLOC_FL_WRITE_ZEROS) so that the filesystem knows that
On Mon, Dec 10, 2012 at 12:37:39PM -0500, Theodore Ts'o wrote:
On Sat, Dec 08, 2012 at 11:17:05AM +1100, Dave Chinner wrote:
I wouldn't recommend XFS_IOC_ALLOCSP as a user-friendly interface.
The concept, however, implemented by a new fallocate()
flag (say FALLOC_FL_WRITE_ZEROS) so that the
On 12/07/2012 04:14 PM, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 02:30:19PM -0500, Steven Rostedt wrote:
How is this similar? By adding this bit, we removed incentive from a
group of developers that have the means to fix the real issue at hand
(the performance problem with ext4). Thus, it
On 12/07/2012 04:14 PM, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 02:30:19PM -0500, Steven Rostedt wrote:
How is this similar? By adding this bit, we removed incentive from a
group of developers that have the means to fix the real issue at hand
(the performance problem with ext4). Thus, it
On 12/08/2012 08:52 AM, Howard Chu wrote:
Dave Chinner wrote:
On Fri, Dec 07, 2012 at 03:25:53PM -0800, Howard Chu wrote:
I have to agree that, if this is going to be an ext4-specific
feature, then it can just be implemented via an ext4-specific ioctl
and be done with it. But I'm not convinced
Dave Chinner wrote:
On Fri, Dec 07, 2012 at 03:25:53PM -0800, Howard Chu wrote:
I have to agree that, if this is going to be an ext4-specific
feature, then it can just be implemented via an ext4-specific ioctl
and be done with it. But I'm not convinced this should be an
ext4-specific feature.
Dave Chinner wrote:
On Fri, Dec 07, 2012 at 03:25:53PM -0800, Howard Chu wrote:
I have to agree that, if this is going to be an ext4-specific
feature, then it can just be implemented via an ext4-specific ioctl
and be done with it. But I'm not convinced this should be an
ext4-specific feature.
On 12/08/2012 08:52 AM, Howard Chu wrote:
Dave Chinner wrote:
On Fri, Dec 07, 2012 at 03:25:53PM -0800, Howard Chu wrote:
I have to agree that, if this is going to be an ext4-specific
feature, then it can just be implemented via an ext4-specific ioctl
and be done with it. But I'm not convinced
On Fri, Dec 07, 2012 at 06:52:51PM -0800, Joel Becker wrote:
> On Sat, Dec 08, 2012 at 11:39:36AM +1100, Dave Chinner wrote:
> > On Fri, Dec 07, 2012 at 05:02:32PM -0500, Ric Wheeler wrote:
> > > On 12/07/2012 04:57 PM, Theodore Ts'o wrote:
> > > >On Fri, Dec 07, 2012 at 04:42:06PM -0500, Ric
On Sat, Dec 08, 2012 at 11:39:36AM +1100, Dave Chinner wrote:
> On Fri, Dec 07, 2012 at 05:02:32PM -0500, Ric Wheeler wrote:
> > On 12/07/2012 04:57 PM, Theodore Ts'o wrote:
> > >On Fri, Dec 07, 2012 at 04:42:06PM -0500, Ric Wheeler wrote:
> > >>The other things that I think we should try would be
On Fri, Dec 07, 2012 at 05:17:05PM -0700, Dave Chinner wrote:
> On Fri, Dec 07, 2012 at 02:03:06PM -0500, Chris Mason wrote:
[ dead and beaten fallocate ponies ]
>
> > On a single flash drive doing random 4K writes, xfs does 950MB/s into
> > regular extents but only 400MB/s into preallocated
On Fri, Dec 07, 2012 at 03:25:53PM -0800, Howard Chu wrote:
> Ric Wheeler wrote:
> >On 12/07/2012 04:14 PM, Theodore Ts'o wrote:
> >>On Fri, Dec 07, 2012 at 02:30:19PM -0500, Steven Rostedt wrote:
> >>>How is this similar? By adding this bit, we removed incentive from a
> >>>group of developers
On Fri, Dec 07, 2012 at 05:02:32PM -0500, Ric Wheeler wrote:
> On 12/07/2012 04:57 PM, Theodore Ts'o wrote:
> >On Fri, Dec 07, 2012 at 04:42:06PM -0500, Ric Wheeler wrote:
> >>The other things that I think we should try would be to convert over
> >>larger chunks as we discussed on the list back in
On Fri, Dec 07, 2012 at 02:03:06PM -0500, Chris Mason wrote:
> On Fri, Dec 07, 2012 at 11:18:00AM -0700, Linus Torvalds wrote:
> >
> >
> > On Fri, 7 Dec 2012, Ric Wheeler wrote:
> > >
> > > Review is part of the way we work as a community and we should figure out
> > > how
> > > to fix our
Ric Wheeler wrote:
On 12/07/2012 04:14 PM, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 02:30:19PM -0500, Steven Rostedt wrote:
How is this similar? By adding this bit, we removed incentive from a
group of developers that have the means to fix the real issue at hand
(the performance problem
On 12/7/12 3:57 PM, Chris Mason wrote:
> On Fri, Dec 07, 2012 at 02:49:04PM -0700, Ric Wheeler wrote:
>> On 12/07/2012 04:43 PM, Chris Mason wrote:
>>> On Fri, Dec 07, 2012 at 02:27:43PM -0700, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 04:09:32PM -0500, Chris Mason wrote:
> Persistent
On 12/7/12 3:57 PM, Chris Mason wrote:
> On Fri, Dec 07, 2012 at 02:49:04PM -0700, Ric Wheeler wrote:
>> On 12/07/2012 04:43 PM, Chris Mason wrote:
>>> On Fri, Dec 07, 2012 at 02:27:43PM -0700, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 04:09:32PM -0500, Chris Mason wrote:
> Persistent
On 12/7/12 3:14 PM, Theodore Ts'o wrote:
> On Fri, Dec 07, 2012 at 02:30:19PM -0500, Steven Rostedt wrote:
>> How is this similar? By adding this bit, we removed incentive from a
>> group of developers that have the means to fix the real issue at hand
>> (the performance problem with ext4). Thus,
On 12/07/2012 04:57 PM, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 04:42:06PM -0500, Ric Wheeler wrote:
The other things that I think we should try would be to convert over
larger chunks as we discussed on the list back in the summer (just
because the user writes 4KB does not mean that we
On Fri, Dec 07, 2012 at 04:42:06PM -0500, Ric Wheeler wrote:
> The other things that I think we should try would be to convert over
> larger chunks as we discussed on the list back in the summer (just
> because the user writes 4KB does not mean that we cannot flip over
> 1MB and zero that).
On Fri, Dec 07, 2012 at 02:49:04PM -0700, Ric Wheeler wrote:
> On 12/07/2012 04:43 PM, Chris Mason wrote:
> > On Fri, Dec 07, 2012 at 02:27:43PM -0700, Theodore Ts'o wrote:
> >> On Fri, Dec 07, 2012 at 04:09:32PM -0500, Chris Mason wrote:
> >>> Persistent trim is what I had in mind, but there are
On 12/07/2012 04:43 PM, Chris Mason wrote:
On Fri, Dec 07, 2012 at 02:27:43PM -0700, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 04:09:32PM -0500, Chris Mason wrote:
Persistent trim is what I had in mind, but there are other ideas that do
imply a change in behavior as well. Can we safely
On 12/07/2012 04:14 PM, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 02:30:19PM -0500, Steven Rostedt wrote:
How is this similar? By adding this bit, we removed incentive from a
group of developers that have the means to fix the real issue at hand
(the performance problem with ext4). Thus, it
On Fri, Dec 07, 2012 at 02:27:43PM -0700, Theodore Ts'o wrote:
> On Fri, Dec 07, 2012 at 04:09:32PM -0500, Chris Mason wrote:
> > Persistent trim is what I had in mind, but there are other ideas that do
> > imply a change in behavior as well. Can we safely assume this feature
> > won't matter on
On 12/07/2012 04:09 PM, Chris Mason wrote:
On Fri, Dec 07, 2012 at 01:43:25PM -0700, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 02:03:06PM -0500, Chris Mason wrote:
That's not what happened though, and the right way forward from here is
to give the bit to the feature, maybe with a generic
On Fri, Dec 07, 2012 at 04:09:32PM -0500, Chris Mason wrote:
> Persistent trim is what I had in mind, but there are other ideas that do
> imply a change in behavior as well. Can we safely assume this feature
> won't matter on spinning media? New features like persistent
> trim do make it much
On Fri, Dec 07, 2012 at 02:30:19PM -0500, Steven Rostedt wrote:
> How is this similar? By adding this bit, we removed incentive from a
> group of developers that have the means to fix the real issue at hand
> (the performance problem with ext4). Thus, it means that they have a work
> around that's
On Fri, Dec 07, 2012 at 01:43:25PM -0700, Theodore Ts'o wrote:
> On Fri, Dec 07, 2012 at 02:03:06PM -0500, Chris Mason wrote:
> >
> > That's not what happened though, and the right way forward from here is
> > to give the bit to the feature, maybe with a generic name like
> >
On Fri, Dec 07, 2012 at 02:03:06PM -0500, Chris Mason wrote:
>
> That's not what happened though, and the right way forward from here is
> to give the bit to the feature, maybe with a generic name like
> FALLOCATE_WITHOUT_BEING_HORRIBLY_SLOW.
I don't think that's a good idea, because the
On Fri, Dec 07, 2012 at 10:18:00AM -0800, Linus Torvalds wrote:
>
> And that's _fine_. Once you have actual technical arguments ("I'd like to
> re-appropriate that bit, because xyzzy") you have real and valid
> arguments, and it would be easy to then do the sane "let's just use the
> bit for
On Fri, Dec 07, 2012 at 11:18:00AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 7 Dec 2012, Ric Wheeler wrote:
> >
> > Review is part of the way we work as a community and we should figure out
> > how
> > to fix our review process so that we can have meaningful results from the
> > review or we
On Fri, 7 Dec 2012, Ric Wheeler wrote:
>
> Review is part of the way we work as a community and we should figure out how
> to fix our review process so that we can have meaningful results from the
> review or we lose confidence in the process and it makes it much harder to get
> reviewers to
On 12/06/2012 08:16 PM, Ingo Molnar wrote:
* Christoph Hellwig wrote:
No, the problem is that the thing is not just a) wrong, but b)
only made it in through sneaky ways.
People disagree with a), and b) only really matters if a) is
true.
You never gave a technical reason for why protecting
Am Freitag, 7. Dezember 2012 schrieb Ingo Molnar:
> * Martin Steigerwald wrote:
>
> > > The thing that people are complaining about is exactly the
> > > reverse of this. It's *protecting* us from making mistakes,
> > > and doesn't actually add any new interfaces in itself.
> > >
> > > This is
Am Freitag, 7. Dezember 2012 schrieb Ingo Molnar:
* Martin Steigerwald mar...@lichtvoll.de wrote:
The thing that people are complaining about is exactly the
reverse of this. It's *protecting* us from making mistakes,
and doesn't actually add any new interfaces in itself.
This
On 12/06/2012 08:16 PM, Ingo Molnar wrote:
* Christoph Hellwig h...@infradead.org wrote:
No, the problem is that the thing is not just a) wrong, but b)
only made it in through sneaky ways.
People disagree with a), and b) only really matters if a) is
true.
You never gave a technical reason
On Fri, 7 Dec 2012, Ric Wheeler wrote:
Review is part of the way we work as a community and we should figure out how
to fix our review process so that we can have meaningful results from the
review or we lose confidence in the process and it makes it much harder to get
reviewers to spend
On Fri, Dec 07, 2012 at 11:18:00AM -0700, Linus Torvalds wrote:
On Fri, 7 Dec 2012, Ric Wheeler wrote:
Review is part of the way we work as a community and we should figure out
how
to fix our review process so that we can have meaningful results from the
review or we lose
On Fri, Dec 07, 2012 at 10:18:00AM -0800, Linus Torvalds wrote:
And that's _fine_. Once you have actual technical arguments (I'd like to
re-appropriate that bit, because xyzzy) you have real and valid
arguments, and it would be easy to then do the sane let's just use the
bit for something
On Fri, Dec 07, 2012 at 02:03:06PM -0500, Chris Mason wrote:
That's not what happened though, and the right way forward from here is
to give the bit to the feature, maybe with a generic name like
FALLOCATE_WITHOUT_BEING_HORRIBLY_SLOW.
I don't think that's a good idea, because the current
On Fri, Dec 07, 2012 at 01:43:25PM -0700, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 02:03:06PM -0500, Chris Mason wrote:
That's not what happened though, and the right way forward from here is
to give the bit to the feature, maybe with a generic name like
On Fri, Dec 07, 2012 at 02:30:19PM -0500, Steven Rostedt wrote:
How is this similar? By adding this bit, we removed incentive from a
group of developers that have the means to fix the real issue at hand
(the performance problem with ext4). Thus, it means that they have a work
around that's
On Fri, Dec 07, 2012 at 04:09:32PM -0500, Chris Mason wrote:
Persistent trim is what I had in mind, but there are other ideas that do
imply a change in behavior as well. Can we safely assume this feature
won't matter on spinning media? New features like persistent
trim do make it much easier
On 12/07/2012 04:09 PM, Chris Mason wrote:
On Fri, Dec 07, 2012 at 01:43:25PM -0700, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 02:03:06PM -0500, Chris Mason wrote:
That's not what happened though, and the right way forward from here is
to give the bit to the feature, maybe with a generic
On Fri, Dec 07, 2012 at 02:27:43PM -0700, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 04:09:32PM -0500, Chris Mason wrote:
Persistent trim is what I had in mind, but there are other ideas that do
imply a change in behavior as well. Can we safely assume this feature
won't matter on
On 12/07/2012 04:14 PM, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 02:30:19PM -0500, Steven Rostedt wrote:
How is this similar? By adding this bit, we removed incentive from a
group of developers that have the means to fix the real issue at hand
(the performance problem with ext4). Thus, it
On 12/07/2012 04:43 PM, Chris Mason wrote:
On Fri, Dec 07, 2012 at 02:27:43PM -0700, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 04:09:32PM -0500, Chris Mason wrote:
Persistent trim is what I had in mind, but there are other ideas that do
imply a change in behavior as well. Can we safely
On Fri, Dec 07, 2012 at 02:49:04PM -0700, Ric Wheeler wrote:
On 12/07/2012 04:43 PM, Chris Mason wrote:
On Fri, Dec 07, 2012 at 02:27:43PM -0700, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 04:09:32PM -0500, Chris Mason wrote:
Persistent trim is what I had in mind, but there are other
On Fri, Dec 07, 2012 at 04:42:06PM -0500, Ric Wheeler wrote:
The other things that I think we should try would be to convert over
larger chunks as we discussed on the list back in the summer (just
because the user writes 4KB does not mean that we cannot flip over
1MB and zero that).
Writing a
On 12/07/2012 04:57 PM, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 04:42:06PM -0500, Ric Wheeler wrote:
The other things that I think we should try would be to convert over
larger chunks as we discussed on the list back in the summer (just
because the user writes 4KB does not mean that we
On 12/7/12 3:14 PM, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 02:30:19PM -0500, Steven Rostedt wrote:
How is this similar? By adding this bit, we removed incentive from a
group of developers that have the means to fix the real issue at hand
(the performance problem with ext4). Thus, it
On 12/7/12 3:57 PM, Chris Mason wrote:
On Fri, Dec 07, 2012 at 02:49:04PM -0700, Ric Wheeler wrote:
On 12/07/2012 04:43 PM, Chris Mason wrote:
On Fri, Dec 07, 2012 at 02:27:43PM -0700, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 04:09:32PM -0500, Chris Mason wrote:
Persistent trim is what I
On 12/7/12 3:57 PM, Chris Mason wrote:
On Fri, Dec 07, 2012 at 02:49:04PM -0700, Ric Wheeler wrote:
On 12/07/2012 04:43 PM, Chris Mason wrote:
On Fri, Dec 07, 2012 at 02:27:43PM -0700, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 04:09:32PM -0500, Chris Mason wrote:
Persistent trim is what I
Ric Wheeler wrote:
On 12/07/2012 04:14 PM, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 02:30:19PM -0500, Steven Rostedt wrote:
How is this similar? By adding this bit, we removed incentive from a
group of developers that have the means to fix the real issue at hand
(the performance problem
On Fri, Dec 07, 2012 at 02:03:06PM -0500, Chris Mason wrote:
On Fri, Dec 07, 2012 at 11:18:00AM -0700, Linus Torvalds wrote:
On Fri, 7 Dec 2012, Ric Wheeler wrote:
Review is part of the way we work as a community and we should figure out
how
to fix our review process so that
On Fri, Dec 07, 2012 at 05:02:32PM -0500, Ric Wheeler wrote:
On 12/07/2012 04:57 PM, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 04:42:06PM -0500, Ric Wheeler wrote:
The other things that I think we should try would be to convert over
larger chunks as we discussed on the list back in the
On Fri, Dec 07, 2012 at 03:25:53PM -0800, Howard Chu wrote:
Ric Wheeler wrote:
On 12/07/2012 04:14 PM, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 02:30:19PM -0500, Steven Rostedt wrote:
How is this similar? By adding this bit, we removed incentive from a
group of developers that have the
On Fri, Dec 07, 2012 at 05:17:05PM -0700, Dave Chinner wrote:
On Fri, Dec 07, 2012 at 02:03:06PM -0500, Chris Mason wrote:
[ dead and beaten fallocate ponies ]
On a single flash drive doing random 4K writes, xfs does 950MB/s into
regular extents but only 400MB/s into preallocated extents.
On Sat, Dec 08, 2012 at 11:39:36AM +1100, Dave Chinner wrote:
On Fri, Dec 07, 2012 at 05:02:32PM -0500, Ric Wheeler wrote:
On 12/07/2012 04:57 PM, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 04:42:06PM -0500, Ric Wheeler wrote:
The other things that I think we should try would be to
On Fri, Dec 07, 2012 at 06:52:51PM -0800, Joel Becker wrote:
On Sat, Dec 08, 2012 at 11:39:36AM +1100, Dave Chinner wrote:
On Fri, Dec 07, 2012 at 05:02:32PM -0500, Ric Wheeler wrote:
On 12/07/2012 04:57 PM, Theodore Ts'o wrote:
On Fri, Dec 07, 2012 at 04:42:06PM -0500, Ric Wheeler wrote:
On Fri, Dec 07, 2012 at 02:16:28AM +0100, Ingo Molnar wrote:
>
> * Christoph Hellwig wrote:
>
> > No, the problem is that the thing is not just a) wrong, but b)
> > only made it in through sneaky ways.
>
> People disagree with a), and b) only really matters if a) is
> true.
Wow.
Let me
On Fri, Dec 07, 2012 at 02:08:37AM +0100, Ingo Molnar wrote:
>
> * Martin Steigerwald wrote:
>
> > > The thing that people are complaining about is exactly the
> > > reverse of this. It's *protecting* us from making mistakes,
> > > and doesn't actually add any new interfaces in itself.
> > >
On Thu, Dec 06, 2012 at 11:50:24AM -0500, Theodore Ts'o wrote:
> On Thu, Dec 06, 2012 at 07:06:45AM -0500, Christoph Hellwig wrote:
> >
> > Also the only conference outcome I remember is that everyone at LSF
> > except for Ted basically said "no fucking way".
> >
>
> At LSF, that's correct.
* Christoph Hellwig wrote:
> No, the problem is that the thing is not just a) wrong, but b)
> only made it in through sneaky ways.
People disagree with a), and b) only really matters if a) is
true.
You never gave a technical reason for why protecting against
future ABI clashes is 'wrong'.
* Martin Steigerwald wrote:
> > The thing that people are complaining about is exactly the
> > reverse of this. It's *protecting* us from making mistakes,
> > and doesn't actually add any new interfaces in itself.
> >
> > This is why I'm so annoyed with this stupid thread. It's
> > been
On Thu, Dec 06, 2012 at 07:06:45AM -0500, Christoph Hellwig wrote:
>
> Also the only conference outcome I remember is that everyone at LSF
> except for Ted basically said "no fucking way".
>
At LSF, that's correct. And as a result, the people who need this --
Google and Tao Bao -- have decided
On Thu, Dec 06, 2012 at 12:14:02PM +1100, Dave Chinner wrote:
> On Wed, Dec 05, 2012 at 10:25:17AM -0800, Linus Torvalds wrote:
> > Yes, people can argue that "process" is about technical issues too,
> > but let's be honest: our process is fluid. Not everything gets
> > reviewed on the mailing
On Wed, Dec 05, 2012 at 07:45:39AM -0800, Linus Torvalds wrote:
> On Wed, Dec 5, 2012 at 2:48 AM, Martin Steigerwald
> wrote:
> >
> > Linus, while I am interested in an answer I think that Dave and Christoph
> > as Linux filesystem developers actually deserve one (instead of silently
> > being
Am Donnerstag, 6. Dezember 2012 schrieb Linus Torvalds:
> On Wed, Dec 5, 2012 at 5:14 PM, Dave Chinner
wrote:
> > And for changes to syscalls? That's something that must be peer
> > reviewed because we are going to be stuck with those changes forever
> > as we can't undo them at a later date. It
Am Donnerstag, 6. Dezember 2012 schrieb Dave Chinner:
> > That being said, you'll note that unlike Dave, I have
> > **not** thrown a hissy fit when btrfs grabbed bits from the inode
> > field, even though quite a bit more bits allocated for the inode
> > flags than the fallocate flags.
>
> IOWs,
Am Donnerstag, 6. Dezember 2012 schrieb Dave Chinner:
That being said, you'll note that unlike Dave, I have
**not** thrown a hissy fit when btrfs grabbed bits from the inode
field, even though quite a bit more bits allocated for the inode
flags than the fallocate flags.
IOWs, pointing
Am Donnerstag, 6. Dezember 2012 schrieb Linus Torvalds:
On Wed, Dec 5, 2012 at 5:14 PM, Dave Chinner da...@fromorbit.com
wrote:
And for changes to syscalls? That's something that must be peer
reviewed because we are going to be stuck with those changes forever
as we can't undo them at a
On Wed, Dec 05, 2012 at 07:45:39AM -0800, Linus Torvalds wrote:
On Wed, Dec 5, 2012 at 2:48 AM, Martin Steigerwald mar...@lichtvoll.de
wrote:
Linus, while I am interested in an answer I think that Dave and Christoph
as Linux filesystem developers actually deserve one (instead of silently
On Thu, Dec 06, 2012 at 12:14:02PM +1100, Dave Chinner wrote:
On Wed, Dec 05, 2012 at 10:25:17AM -0800, Linus Torvalds wrote:
Yes, people can argue that process is about technical issues too,
but let's be honest: our process is fluid. Not everything gets
reviewed on the mailing list, and
On Thu, Dec 06, 2012 at 07:06:45AM -0500, Christoph Hellwig wrote:
Also the only conference outcome I remember is that everyone at LSF
except for Ted basically said no fucking way.
At LSF, that's correct. And as a result, the people who need this --
Google and Tao Bao -- have decided to
* Martin Steigerwald mar...@lichtvoll.de wrote:
The thing that people are complaining about is exactly the
reverse of this. It's *protecting* us from making mistakes,
and doesn't actually add any new interfaces in itself.
This is why I'm so annoyed with this stupid thread. It's
* Christoph Hellwig h...@infradead.org wrote:
No, the problem is that the thing is not just a) wrong, but b)
only made it in through sneaky ways.
People disagree with a), and b) only really matters if a) is
true.
You never gave a technical reason for why protecting against
future ABI
On Thu, Dec 06, 2012 at 11:50:24AM -0500, Theodore Ts'o wrote:
On Thu, Dec 06, 2012 at 07:06:45AM -0500, Christoph Hellwig wrote:
Also the only conference outcome I remember is that everyone at LSF
except for Ted basically said no fucking way.
At LSF, that's correct. And as a
On Fri, Dec 07, 2012 at 02:08:37AM +0100, Ingo Molnar wrote:
* Martin Steigerwald mar...@lichtvoll.de wrote:
The thing that people are complaining about is exactly the
reverse of this. It's *protecting* us from making mistakes,
and doesn't actually add any new interfaces in itself.
On Fri, Dec 07, 2012 at 02:16:28AM +0100, Ingo Molnar wrote:
* Christoph Hellwig h...@infradead.org wrote:
No, the problem is that the thing is not just a) wrong, but b)
only made it in through sneaky ways.
People disagree with a), and b) only really matters if a) is
true.
Wow.
On Wed, Dec 5, 2012 at 5:14 PM, Dave Chinner wrote:
>
> And for changes to syscalls? That's something that must be peer
> reviewed because we are going to be stuck with those changes forever
> as we can't undo them at a later date. It doesn't matter who made the
> change in question, I would have
On Wed, Dec 05, 2012 at 10:25:17AM -0800, Linus Torvalds wrote:
> Yes, people can argue that "process" is about technical issues too,
> but let's be honest: our process is fluid. Not everything gets
> reviewed on the mailing list, and people *do* talk about things
> face-to-face at conferences.
On Wed, Dec 05, 2012 at 12:34:15PM -0500, Theodore Ts'o wrote:
> Because it's the on-disk encoding, when btrfs uses extra bits for its
> btrfs-specific inode flags, it means that I need to avoid using those
> bits in ext4, if it's a flag that needs to also be exposed via
> chattr/lsattr.
What,
On Wed, Dec 5, 2012 at 8:18 AM, Martin Steigerwald wrote:
>
> Did you actually *read* the thread, Linus?
I did. And I actually understood it. Unlike some people.
> Dave provided technical reasons.
>
> First in the patch description and then in:
>
> https://lkml.org/lkml/2012/11/26/700
No. That
1 - 100 of 134 matches
Mail list logo
