On 02/25/2013 04:14 PM, Andy Lutomirski wrote:
On 02/21/2013 02:24 PM, Zach Brown wrote:
On Thu, Feb 21, 2013 at 08:50:27PM +, Myklebust, Trond wrote:
On Thu, 2013-02-21 at 21:00 +0100, Paolo Bonzini wrote:
Il 21/02/2013 15:57, Ric Wheeler ha scritto:
sendfile64() pretty much already has
We have debated the need to have a system call to allow for offloading copy
operations, for example to an NFS server (part to the new NFS 4.2
specification), SCSI target device (two different SCSI commands do this), local
file systems (reflink, etc) and I suspect many other possible parts of t
On 02/21/2013 02:51 PM, Myklebust, Trond wrote:
On Thu, 2013-02-21 at 12:37 +0100, Ric Wheeler wrote:
We have debated the need to have a system call to allow for offloading copy
operations, for example to an NFS server (part to the new NFS 4.2
specification), SCSI target device (two different
On 02/21/2013 09:00 PM, Paolo Bonzini wrote:
Il 21/02/2013 15:57, Ric Wheeler ha scritto:
sendfile64() pretty much already has the right arguments for a
"copyfile", however it would be nice to add a 'flags' parameter: the
NFSv4.2 version would use that to specify whether
On 02/21/2013 11:13 PM, Myklebust, Trond wrote:
On Thu, 2013-02-21 at 23:05 +0100, Ric Wheeler wrote:
On 02/21/2013 09:00 PM, Paolo Bonzini wrote:
Il 21/02/2013 15:57, Ric Wheeler ha scritto:
sendfile64() pretty much already has the right arguments for a
"copyfile", however it wou
On 02/22/2013 10:47 AM, Paolo Bonzini wrote:
Il 21/02/2013 23:24, Zach Brown ha scritto:
You could make it work with some locking and out_fd seeking to set the
write offset before calling sendfile64()+flags, but ugh.
ssize_t sendfile(int out_fd, int in_fd, off_t in_offset, off_t
On 10/24/2012 12:15 AM, Nix wrote:
On 24 Oct 2012, Eric Sandeen uttered the following:
On 10/23/12 3:57 PM, Nix wrote:
The only unusual thing about the filesystems on this machine are that
they have hardware RAID-5 (using the Areca driver), so I'm mounting with
'nobarrier':
I should have read
On 09/12/2013 11:36 AM, Chris Mason wrote:
Mark Fasheh's offline dedup work is also here. In this case offline
means the FS is mounted and active, but the dedup work is not done
inline during file IO. This is a building block where utilities are
able to ask the FS to dedup a series of extents
On 09/26/2013 11:34 AM, J. Bruce Fields wrote:
On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown wrote:
A client-side copy will be slower, but I guess it does have the
advantage that the application can track progress to some degree, a
On 09/26/2013 03:53 PM, Miklos Szeredi wrote:
On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown wrote:
But I'm not sure it's worth the effort; 99% of the use of this
interface will be copying whole files. And for that perhaps we need a
different API, one which has been discussed some time ago:
asyn
On 09/26/2013 02:55 PM, Zach Brown wrote:
On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown wrote:
A client-side copy will be slower, but I guess it does have the
advantage that the application can track progress to some degree, and
ab
On 09/27/2013 12:47 AM, Miklos Szeredi wrote:
On Thu, Sep 26, 2013 at 11:23 PM, Ric Wheeler wrote:
On 09/26/2013 03:53 PM, Miklos Szeredi wrote:
On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown wrote:
But I'm not sure it's worth the effort; 99% of the use of this
interface will be cop
On 09/28/2013 11:20 AM, Myklebust, Trond wrote:
-Original Message-
From: Miklos Szeredi [mailto:mik...@szeredi.hu]
Sent: Saturday, September 28, 2013 12:50 AM
To: Zach Brown
Cc: J. Bruce Fields; Ric Wheeler; Anna Schumaker; Kernel Mailing List; Linux-
Fsdevel; linux-...@vger.kernel.org
On 09/30/2013 10:34 AM, J. Bruce Fields wrote:
On Mon, Sep 30, 2013 at 02:20:30PM +0200, Miklos Szeredi wrote:
On Sat, Sep 28, 2013 at 11:20 PM, Ric Wheeler wrote:
I don't see the safety argument very compelling either. There are real
semantic differences, however: ENOSPC on a write
On 09/30/2013 10:51 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields wrote:
My other worry is about interruptibility/restartability. Ideas?
What happens on splice(from, to, 4G) and it's a non-reflink copy?
Can the page cache copy be made restartable? Or should spli
On 09/30/2013 10:24 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:52 PM, Ric Wheeler wrote:
On 09/30/2013 10:51 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields
wrote:
My other worry is about interruptibility/restartability. Ideas?
What happens on splice
On 09/30/2013 10:38 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:28 PM, Ric Wheeler wrote:
On 09/30/2013 10:24 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:52 PM, Ric Wheeler wrote:
On 09/30/2013 10:51 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields
On 09/30/2013 10:46 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:41 PM, Ric Wheeler wrote:
The way the array based offload (and some software side reflink works) is
not a byte by byte copy. We cannot assume that a valid count can be returned
or that such a count would be an indication
On 09/30/2013 04:00 PM, Bernd Schubert wrote:
pNFS, FhGFS, Lustre, Ceph, etc., all of them shall implement their own
interface? And userspace needs to address all of them differently?
The NFS and SCSI groups have each defined a standard which Zach's proposal
abstracts into a common user API.
On 09/05/2012 10:41 AM, Paolo Bonzini wrote:
Il 28/08/2012 13:04, Paolo Bonzini ha scritto:
Il 01/08/2012 17:53, Paolo Bonzini ha scritto:
Il 20/07/2012 18:30, Paolo Bonzini ha scritto:
These commands cannot be issued right now without giving CAP_SYS_RAWIO to
the process who wishes to send the
On 09/06/2012 02:31 AM, Paolo Bonzini wrote:
Il 05/09/2012 22:18, Ric Wheeler ha scritto:
Hi Paolo,
Both of these commands are destructive. WRITE_SAME (if done without the
discard bits set) can also take a very long time to be destructive and
tie up the storage.
FORMAT_UNIT has the same
On 09/06/2012 07:49 AM, Paolo Bonzini wrote:
Il 06/09/2012 13:31, Ric Wheeler ha scritto:
Both of these commands are destructive. WRITE_SAME (if done without the
discard bits set) can also take a very long time to be destructive and
tie up the storage.
FORMAT_UNIT has the same characteristics
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 ag
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 nam
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 me
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 assu
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 th
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 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 me
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 11/16/2012 10:06 AM, Howard Chu wrote:
David Lang wrote:
barriers keep getting mentioned because they are a easy concept to understand.
"do this set of stuff before doing any of this other set of stuff, but I don't
care when any of this gets done" and they fit well with the requirements of th
On 11/16/2012 10:54 AM, Howard Chu wrote:
Ric Wheeler wrote:
On 11/16/2012 10:06 AM, Howard Chu wrote:
David Lang wrote:
barriers keep getting mentioned because they are a easy concept to understand.
"do this set of stuff before doing any of this other set of stuff, but I don't
car
On 07/16/2013 07:12 PM, Sarah Sharp wrote:
On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote:
On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote:
Yes, that's true. Some kernel developers are better at moderating their
comments and tone towards individuals who are "sensitive".
On 07/16/2013 07:53 PM, Myklebust, Trond wrote:
On Tue, 2013-07-16 at 19:31 -0400, Ric Wheeler wrote:
On 07/16/2013 07:12 PM, Sarah Sharp wrote:
On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote:
On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote:
Yes, that's true.
On 08/23/2013 05:10 AM, Eiichi Tsukata wrote:
(2013/08/21 3:09), Ewan Milne wrote:
On Tue, 2013-08-20 at 16:13 +0900, Eiichi Tsukata wrote:
(2013/08/19 23:30), James Bottomley wrote:
On Mon, 2013-08-19 at 18:39 +0900, Eiichi Tsukata wrote:
Hello,
This patch adds scsi device failfast mode to
On 07/17/2013 12:52 AM, James Bottomley wrote:
On Tue, 2013-07-16 at 15:15 -0600, Jens Axboe wrote:
On Tue, Jul 16 2013, Nicholas A. Bellinger wrote:
On Sat, 2013-07-13 at 06:53 +, James Bottomley wrote:
On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote:
On 07/12/2013 03:33 AM, Nic
On 07/20/2013 01:04 PM, Ben Hutchings wrote:
n Fri, 2013-07-19 at 13:42 -0500, Felipe Contreras wrote:
>On Fri, Jul 19, 2013 at 7:08 AM, Ingo Molnar wrote:
> >
> >* Felipe Contreras wrote:
>
> >>As Linus already pointed out, not everybody has to work with everybody.
> >
> >That's not the p
On 05/15/2013 04:03 PM, Zach Brown wrote:
On Wed, May 15, 2013 at 07:44:05PM +, Eric Wong wrote:
Why introduce a new syscall instead of extending sys_splice?
Personally, I think it's ugly to have different operations use the same
syscall just because their arguments match.
I agree with Za
On 03/30/2013 05:57 PM, Myklebust, Trond wrote:
On Mar 30, 2013, at 5:45 PM, Pavel Machek
wrote:
On Sat 2013-03-30 13:08:39, Andreas Dilger wrote:
On 2013-03-30, at 12:49 PM, Pavel Machek wrote:
Hmm, really? AFAICT it would be simple to provide an
open_deleted_file("directory") syscall. Yo
On 03/31/2013 06:50 PM, Pavel Machek wrote:
On Sun 2013-03-31 18:44:53, Myklebust, Trond wrote:
On Sun, 2013-03-31 at 20:32 +0200, Pavel Machek wrote:
Hmm. open_deleted_file() will still need to get a directory... so it
will still need a path. Perhaps open("/foo/bar/mnt", O_DELETED) would
be ac
On 03/31/2013 07:18 PM, Pavel Machek wrote:
Hi!
Take a look at how many actively used filesystems out there that have
some variant of sillyrename(), and explain what you want to do in those
cases.
Well. Yes, there are non-unix filesystems around. You have to deal
with silly files on them, and
Alasdair G Kergon wrote:
On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
I wonder if it's worth the effort to try to implement this.
My personal view (which seems to be in the minority) is that it's a
waste of our de
Michael Tokarev wrote:
Ric Wheeler wrote:
Alasdair G Kergon wrote:
On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
I wonder if it's worth the effort to try to implement this.
My personal view (which seems to
Jeremy Higdon wrote:
On Tue, Feb 19, 2008 at 09:16:44AM +1100, David Chinner wrote:
On Mon, Feb 18, 2008 at 04:24:27PM +0300, Michael Tokarev wrote:
First, I still don't understand why in God's sake barriers are "working"
while regular cache flushes are not. Almost no consumer-grade hard drive
On 09/25/2012 04:08 PM, James Bottomley wrote:
On Tue, 2012-09-25 at 01:21 -0400, Jeff Garzik wrote:
On 09/25/2012 12:06 AM, James Bottomley wrote:
On Mon, 2012-09-24 at 17:00 -0400, Jeff Garzik wrote:
drivers/scsi/sd.c |4
drivers/scsi/sd.h |2 +-
2 files changed, 5 insert
Jeff Garzik wrote:
Jamie Lokier wrote:
By durable, I mean that fsync() should actually commit writes to
physical stable storage,
Yes, it should.
I was surprised that fsync() doesn't do this already. There was a lot
of effort put into block I/O write barriers during 2.5, so that
journalling
On 12/03/2012 09:34 PM, Keith Chew wrote:
Hi
Just wanted to check if the "'Data=guarded' mode in Ext3" work started
by Chris Mason, is still being considered for merging to the mainline
kernel? Or has that effort stopped?
Regards
Keith
Hi Keith,
I think that Chris is spending pretty much al
There are two parts of MOSIX that deal with file systems.
In MOSIX, every migrated process leaves a proxy at its creation (home)
node that services all system call requests, including IO calls.
What newer versions of MOSIX did is to add the "DFSA" (direct file
system access) layer that allows MOS
Patrick, Hebert,
This issues stills seems to be in the latest trees - is this patch or a
variation on it still bumping around?
Thanks!
Yair Itzhaki wrote:
Can anyone propose a patch that I can start checking?
I have come up with the following:
--- net/core/netfilter.c.orig 2005-04-18 2
Theodore Tso wrote:
On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote:
But I heard some years ago from a disk drive engineer that that is a myth
just like the rotational energy thing. I added that to the discussion,
but admitted that I haven't actually seen a disk drive write a p
Pavel Machek wrote:
On Sat 2008-01-12 09:51:40, Theodore Tso wrote:
On Wed, Jan 09, 2008 at 02:52:14PM +0300, Al Boldi wrote:
Ok, but let's look at this a bit more opportunistic / optimistic.
Even after a black-out shutdown, the corruption is pretty minimal, using
ext3fs at least.
After a
Andrew Morton wrote:
I'm wondering about the real value of this change, really.
In any decent environment, people will fsck their ext3 filesystems during
planned downtime, and the benefit of reducing that downtime from 6
hours/machine to 2 hours/machine is probably fairly small, given that there
Theodore Tso wrote:
On Wed, Jan 16, 2008 at 09:02:50PM -0500, Daniel Phillips wrote:
Have you observed that in the wild? A former engineer of a disk drive
company suggests to me that the capacitors on the board provide enough
power to complete the last sector, even to park the head.
Even if
Having looked at a lot of disks, I think that it is definitely worth
forcing a write to try and invoke the remap. With large drives, you
usually several bad sectors in the normal case (drive vendors allocate
up to a couple thousand spare sectors just for remapping).
Depending on the type of dr
Zach Brown wrote:
Can you clarify what you mean above with an example? I don't really
follow.
Sure, take 'tar' as an example. It'll read files in the order that
their names are returned from directory listing. This can produce bad
IO patterns because the order in which the file names are ret
Zach Brown wrote:
The second use case is to look at the physical layout of blocks on disk
for a specific file, use Mark Lord's write_long patches to inject a disk
error and then read that file to make sure that we are handling disk IO
errors correctly. A bit obscure, but really quite useful.
H
Pavel Machek wrote:
Hi!
Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open
file descriptor.
It would be nice to allow users to have permission to see where their data is
landing on disk, and there really isn't a good reason to keep them from getting
at this inform
Jens Axboe wrote:
On Wed, Feb 21 2007, Tejun Heo wrote:
[cc'ing Ric, Hannes and Dongjun, Hello. Feel free to drag other people in.]
Robert Hancock wrote:
Jens Axboe wrote:
But we can't really change that, since you need the cache flushed before
issuing the FUA write. I've been advocating for
Tejun Heo wrote:
[cc'ing Ric, Hannes and Dongjun, Hello. Feel free to drag other people in.]
Robert Hancock wrote:
Jens Axboe wrote:
But we can't really change that, since you need the cache flushed before
issuing the FUA write. I've been advocating for an ordered bit for
years, so that we co
Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Feb 21 2007, Tejun Heo wrote:
[cc'ing Ric, Hannes and Dongjun, Hello. Feel free to drag other people in.]
Robert Hancock wrote:
Jens Axboe wrote:
But we can't really change that, since you need the cache flushed before
issuing the FUA write. I've b
Mark Lord wrote:
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries. With existing ATA error recovery in the
drives, that's about 3 seconds per retry on average, or 12 seconds
per failure. Multiply that by the number of blocks pa
Jeff Garzik wrote:
Mark Lord wrote:
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries. With existing ATA error recovery in the
drives, that's about 3 seconds per retry on average, or 12 seconds
per failure. Multiply that by the n
Alan wrote:
When libata reports a MEDIUM_ERROR to us, we *know* it's non-recoverable,
as the drive itself has already done internal retries (libata uses the
"with retry" ATA opcodes for this).
This depends on the firmware. Some of the "raid firmware" drives don't
appear to do retries in firmw
James Bottomley wrote:
On Thu, 2007-02-01 at 15:02 -0500, Mark Lord wrote:
I believe you made the first change in response to my prodding at the time,
when libata was not returning valid sense data (no LBA) for media errors.
The SCSI EH handling of that was rather poor at the time,
and so
James Bottomley wrote:
On Fri, 2007-02-02 at 14:42 +, Alan wrote:
The interesting point of this question is about the typically pattern of
IO errors. On a read, it is safe to assume that you will have issues
with some bounded numbers of adjacent sectors.
Which in theory you can
Tejun Heo wrote:
[ cc'ing Ric Wheeler for storage array thingie. Hi, whole thread is at
http://thread.gmane.org/gmane.linux.kernel.device-mapper.devel/3344 ]
I am actually on the list, just really, really far behind in the thread ;-)
Hello,
[EMAIL PROTECTED] wrote:
but whe
[EMAIL PROTECTED] wrote:
On Tue, 10 Jul 2007 14:39:41 EDT, Ric Wheeler said:
All of the high end arrays have non-volatile cache (read, on power loss, it is a
promise that it will get all of your data out to permanent storage). You don't
need to ask this kind of array to drain the cach
[EMAIL PROTECTED] wrote:
On Wed, 11 Jul 2007 18:44:21 EDT, Ric Wheeler said:
[EMAIL PROTECTED] wrote:
On Tue, 10 Jul 2007 14:39:41 EDT, Ric Wheeler said:
All of the high end arrays have non-volatile cache (read, on power loss, it is a
promise that it will get all of your data out to
} development; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
} [EMAIL PROTECTED]; Jens Axboe; David Chinner; Andreas Dilger
} Subject: Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for
} devices, filesystems, and dm/md.
}
} On Wed, 11 Jul 2007 18:44:21 EDT, Ric Wheeler said:
} > [EM
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:
Mark Rustad wrote:
On Mar 27, 2007, at 1:38 PM, Jeff Garzik wrote:
Mark Rustad wrote:
reorder any queued operations. Of course if you really care about
your data, you don't really want to turn write cache on.
That's a gross exaggeration. FLUSH CACHE and FUA both ensure data
integrity as
Bob Bell wrote:
On Sat, Sep 01, 2007 at 08:43:49PM -0600, Matthew Wilcox wrote:
Here's the second version of TASK_KILLABLE. A few changes since
version 1:
I obviously haven't covered every place that can result in a process
sleeping uninterruptibly while attempting an operation. But sync_pa
J. Bruce Fields wrote:
On Tue, Aug 21, 2007 at 02:50:42PM -0400, John Stoffel wrote:
Not in my experience. We use NetApps as our backing NFS servers, so
maybe my experience isn't totally relevant. But with a mix of Linux
and Solaris clients, we've never had problems with soft,intr on our
NF
One topic that has been lurking forever at the edges is the current 4k
limitation for file system block sizes. Some devices in production today and
others coming soon have larger sectors and it would be interesting to see if it
is time to poke at this topic again.
LSF/MM seems to be pretty muc
On 01/22/2014 04:34 AM, Mel Gorman wrote:
On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric Wheeler wrote:
One topic that has been lurking forever at the edges is the current
4k limitation for file system block sizes. Some devices in
production today and others coming soon have larger sectors and
On 01/22/2014 09:34 AM, Mel Gorman wrote:
On Wed, Jan 22, 2014 at 09:10:48AM -0500, Ric Wheeler wrote:
On 01/22/2014 04:34 AM, Mel Gorman wrote:
On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric Wheeler wrote:
One topic that has been lurking forever at the edges is the current
4k limitation for
On 01/22/2014 11:03 AM, James Bottomley wrote:
On Wed, 2014-01-22 at 15:14 +, Chris Mason wrote:
On Wed, 2014-01-22 at 09:34 +, Mel Gorman wrote:
On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric Wheeler wrote:
One topic that has been lurking forever at the edges is the current
4k
On 01/22/2014 01:13 PM, James Bottomley wrote:
On Wed, 2014-01-22 at 18:02 +, Chris Mason wrote:
On Wed, 2014-01-22 at 09:21 -0800, James Bottomley wrote:
On Wed, 2014-01-22 at 17:02 +, Chris Mason wrote:
[ I like big sectors and I cannot lie ]
I think I might be sceptical, but I don'
On 01/22/2014 01:35 PM, James Bottomley wrote:
On Wed, 2014-01-22 at 13:17 -0500, Ric Wheeler wrote:
On 01/22/2014 01:13 PM, James Bottomley wrote:
On Wed, 2014-01-22 at 18:02 +, Chris Mason wrote:
On Wed, 2014-01-22 at 09:21 -0800, James Bottomley wrote:
On Wed, 2014-01-22 at 17:02
On 01/22/2014 01:37 PM, Chris Mason wrote:
> Circling back to what we might talk about at the conference, Ric do you
> have any ideas on when these drives might hit the wild?
>
> -chris
I will poke at vendors to see if we can get someone to make a public statement,
but I cannot do that for them.
e are going to add a co-maintainer for XFS, we really need to have one of our
two leading developers in that role.
Best regards,
Ric
On 11/07/2013 09:23 PM, Ric Wheeler wrote:
Hi Ben,
How exactly did we decide to add a new co-maintainer? Shouldn't we have some
discussion on the list an
On 11/08/2013 01:03 PM, Ben Myers wrote:
Hey Ric,
On Fri, Nov 08, 2013 at 06:03:41AM -0500, Ric Wheeler wrote:
In the XFS community, we have 2 clear leaders in terms of
contributions of significant feaures and depth of knowledge -
Christoph and Dave.
If you look at the number of patches
On 11/08/2013 02:34 PM, Christoph Hellwig wrote:
On Fri, Nov 08, 2013 at 12:03:37PM -0600, Ben Myers wrote:
Mark is replacing Alex as my backup because Alex is really busy at
Linaro and asked to be taken off awhile ago. The holiday season is
coming up and I fully intend to go off my meds, turn
On 11/08/2013 03:46 PM, Ben Myers wrote:
Hey Christoph,
On Fri, Nov 08, 2013 at 11:34:24AM -0800, Christoph Hellwig wrote:
On Fri, Nov 08, 2013 at 12:03:37PM -0600, Ben Myers wrote:
Mark is replacing Alex as my backup because Alex is really busy at
Linaro and asked to be taken off awhile ago.
On 11/08/2013 05:03 PM, Ben Myers wrote:
Hey Ric,
On Fri, Nov 08, 2013 at 03:50:21PM -0500, Ric Wheeler wrote:
On 11/08/2013 03:46 PM, Ben Myers wrote:
Hey Christoph,
On Fri, Nov 08, 2013 at 11:34:24AM -0800, Christoph Hellwig wrote:
On Fri, Nov 08, 2013 at 12:03:37PM -0600, Ben Myers wrote
On 11/08/2013 05:17 PM, Ben Myers wrote:
Hey Ric,
On Fri, Nov 08, 2013 at 05:07:45PM -0500, Ric Wheeler wrote:
On 11/08/2013 05:03 PM, Ben Myers wrote:
Hey Ric,
On Fri, Nov 08, 2013 at 03:50:21PM -0500, Ric Wheeler wrote:
On 11/08/2013 03:46 PM, Ben Myers wrote:
Hey Christoph,
On Fri, Nov
On 11/22/2013 03:01 PM, Stefan Priebe wrote:
Hi Christoph,
Am 21.11.2013 11:11, schrieb Christoph Hellwig:
2. Some drives may implement CMD_FLUSH to return immediately i.e. no
guarantee the data is actually on disk.
In which case they aren't spec complicant. While I've seen countless
data in
On 11/23/2013 01:27 PM, Stefan Priebe wrote:
Hi Ric,
Am 22.11.2013 21:37, schrieb Ric Wheeler:
On 11/22/2013 03:01 PM, Stefan Priebe wrote:
Hi Christoph,
Am 21.11.2013 11:11, schrieb Christoph Hellwig:
2. Some drives may implement CMD_FLUSH to return immediately i.e. no
guarantee the data
On 11/23/2013 03:36 PM, Pavel Machek wrote:
On Wed 2013-11-20 08:02:33, Howard Chu wrote:
Theodore Ts'o wrote:
Historically, Intel has been really good about avoiding this, but
since they've moved to using 3rd party flash controllers, I now advise
everyone who plans to use any flash storage, re
On 11/23/2013 07:22 PM, Pavel Machek wrote:
On Sat 2013-11-23 18:01:32, Ric Wheeler wrote:
On 11/23/2013 03:36 PM, Pavel Machek wrote:
On Wed 2013-11-20 08:02:33, Howard Chu wrote:
Theodore Ts'o wrote:
Historically, Intel has been really good about avoiding this, but
since they'v
I would like to attend this year and continue to talk about the work on enabling
the new class of persistent memory devices. Specifically, very interested in
talking about both using a block driver under our existing stack and also
progress at the file system layer (adding xip/mmap tweaks to e
On 12/23/2013 09:35 PM, Martin K. Petersen wrote:
"Christoph" == Christoph Hellwig writes:
Christoph> We have the block integrity code to support DIF/DIX in the
Christoph> the tree for about 5 and a half years, and we still don't
Christoph> have a single consumer of it.
What do you mean? If yo
on why I didn't was
that people like Ric Wheeler threatened to have distro-specific
patches to disable the feature, and at the end of the day, I didn't
care that much. After all, if it makes it harder for large scale
cloud companies besides Google to create more efficient userspace
clust
On 03/17/2016 01:47 PM, Linus Torvalds wrote:
On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote:
So we've not asked for NO_HIDE_STALE on the mailing lists, but I think
it was one of the problems Sage had using xfs in his BlueStore
implementation and was a big part of why it moved to pure u
On 03/16/2016 06:23 PM, Chris Mason wrote:
On Tue, Mar 15, 2016 at 05:51:17PM -0700, Chris Mason wrote:
On Tue, Mar 15, 2016 at 07:30:14PM -0500, Eric Sandeen wrote:
On 3/15/16 7:06 PM, Linus Torvalds wrote:
On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote:
It is pretty clear that the onu
I would like to nominate Sage Weil with his consent.
Sage has lead the ceph project since its inception, contributed to the kernel as
well as had an influence on projects like openstack.
thanks!
Ric
On 10/06/2015 01:06 PM, Grant Likely wrote:
[Resending because I messed up the first one]
On 2/6/19 4:12 PM, Dan Williams wrote:
Before people get too excited this isn't a proposal to kill DAX. The
topic proposal is a discussion to resolve lingering open questions
that currently motivate ext4 and xfs to scream "EXPERIMENTAL" when the
current DAX facilities are enabled. The are 2 prima
On 03/11/2016 12:03 AM, Linus Torvalds wrote:
On Thu, Mar 10, 2016 at 6:58 AM, Ric Wheeler wrote:
What was objectionable at the time this patch was raised years back (not
just to me, but to pretty much every fs developer at LSF/MM that year)
centered on the concern that this would be viewed as
On 03/13/2016 07:30 PM, Dave Chinner wrote:
On Fri, Mar 11, 2016 at 04:44:16PM -0800, Linus Torvalds wrote:
On Fri, Mar 11, 2016 at 4:35 PM, Theodore Ts'o wrote:
At the end of the day it's about whether you trust the userspace
program or not.
There's a big difference between "give the user ro
99 matches
Mail list logo
