Re: Will Mosix go into the standard kernel?

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

Re: Testing framework

Avishay Traeger wrote: On Mon, 2007-04-23 at 02:16 +0530, Karuna sagar K wrote: For some time I had been working on this file system test framework. Now I have a implementation for the same and below is the explanation. Any comments are welcome. snip You may want to check out the paper

Re: libata FUA revisited

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

Re: libata FUA revisited

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

Re: libata FUA revisited

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

Re: Why is NCQ enabled by default by libata? (2.6.20)

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

Re: [RFD] Incremental fsck

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

Re: [patch 0/6][RFC] Cleanup FIBMAP

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

Re: [patch 0/6][RFC] Cleanup FIBMAP

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.

Re: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)

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

Re: [PATCH] TASK_KILLABLE version 2

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: snip I obviously haven't covered every place that can result in a process sleeping uninterruptibly while attempting an operation. But

Re: NFS hang + umount -f: better behaviour requested.

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

Re: Re-routing packets via netfilter (ip_rt_bug)

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

Re: raid 1 - automatic 'repair' possible?

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

Re: New copyfile system call - discuss before LSF?

On 03/30/2013 05:57 PM, Myklebust, Trond wrote: On Mar 30, 2013, at 5:45 PM, Pavel Machek pa...@ucw.cz 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)

Re: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?

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

Re: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?

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

New copyfile system call - discuss before LSF?

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

Re: New copyfile system call - discuss before LSF?

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

Re: New copyfile system call - discuss before LSF?

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 or not to copy file

Re: New copyfile system call - discuss before LSF?

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 would be nice

Re: New copyfile system call - discuss before LSF?

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

Re: New copyfile system call - discuss before LSF?

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

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

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

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

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

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

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

Re: [Ping^3] Re: [PATCH] sg_io: allow UNMAP and WRITE SAME without CAP_SYS_RAWIO

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

Re: [Ping^3] Re: [PATCH] sg_io: allow UNMAP and WRITE SAME without CAP_SYS_RAWIO

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

Re: [Ping^3] Re: [PATCH] sg_io: allow UNMAP and WRITE SAME without CAP_SYS_RAWIO

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

Re: [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.24-rc6 -mm patch]

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

Re: [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck)

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

Re: [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck)

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

Re: [dm-devel] Re: [PATCH] Implement barrier support for single device DM devices

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

Re: [dm-devel] Re: [PATCH] Implement barrier support for single device DM devices

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

Re: [dm-devel] Re: [PATCH] Implement barrier support for single device DM devices

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

Re: Proposal for proper durable fsync() and fdatasync()

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

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

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

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

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

Re: [patch 1/1] Drop CAP_SYS_RAWIO requirement for FIBMAP

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

Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

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

Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

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

Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

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

Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

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

Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

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

Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

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

Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

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

Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

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

Re: [sqlite] light weight write barriers

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 the

Re: [sqlite] light weight write barriers

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 care when any

Re: [SCSI PATCH] sd: max-retries becomes configurable

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

Re: data=guarded mode in ext3

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 all

Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.

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 when you

Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.

[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 cache

Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.

[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

Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.

} 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: } [EMAIL

Re: [RFC PATCH] scsi: Add failfast mode to avoid infinite retry loop

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

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

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.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

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. Some

Re: [Ksummit-2013-discuss] [ATTEND] scsi-mq prototype discussion

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,

XFS leadership and a new co-maintainer candidate

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 and see some substantial history

Re: XFS leadership and a new co-maintainer candidate

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

Re: XFS leadership and a new co-maintainer candidate

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

Re: XFS leadership and a new co-maintainer candidate

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.

Re: [PATCH] update xfs maintainers

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

Re: [PATCH] update xfs maintainers

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

Re: [GIT PULL] Btrfs

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

Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

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

Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

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

Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

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: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

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've moved

Re: [RFC v0 1/4] vfs: add copy_range syscall and vfs entry point

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

Re: [RFC] extending splice for copy offloading

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 z...@redhat.com wrote: A client-side copy will be slower, but I guess it does have the advantage that the application can track progress

Re: [RFC] extending splice for copy offloading

On 09/26/2013 03:53 PM, Miklos Szeredi wrote: On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown z...@redhat.com 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

Re: [RFC] extending splice for copy offloading

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 z...@redhat.com wrote: A client-side copy will be slower, but I guess it does have the advantage that the application can track progress to

Re: [RFC] extending splice for copy offloading

On 09/27/2013 12:47 AM, Miklos Szeredi wrote: On Thu, Sep 26, 2013 at 11:23 PM, Ric Wheeler rwhee...@redhat.com wrote: On 09/26/2013 03:53 PM, Miklos Szeredi wrote: On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown z...@redhat.com wrote: But I'm not sure it's worth the effort; 99% of the use

Re: [RFC] extending splice for copy offloading

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

Re: [RFC] extending splice for copy offloading

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 rwhee...@redhat.com wrote: I don't see the safety argument very compelling either. There are real semantic differences, however: ENOSPC

Re: [RFC] extending splice for copy offloading

On 09/30/2013 10:51 AM, Miklos Szeredi wrote: On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields bfie...@fieldses.org 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

Re: [RFC] extending splice for copy offloading

On 09/30/2013 10:24 AM, Miklos Szeredi wrote: On Mon, Sep 30, 2013 at 4:52 PM, Ric Wheeler rwhee...@redhat.com wrote: On 09/30/2013 10:51 AM, Miklos Szeredi wrote: On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields bfie...@fieldses.org wrote: My other worry is about interruptibility

Re: [RFC] extending splice for copy offloading

On 09/30/2013 10:38 AM, Miklos Szeredi wrote: On Mon, Sep 30, 2013 at 4:28 PM, Ric Wheeler rwhee...@redhat.com wrote: On 09/30/2013 10:24 AM, Miklos Szeredi wrote: On Mon, Sep 30, 2013 at 4:52 PM, Ric Wheeler rwhee...@redhat.com wrote: On 09/30/2013 10:51 AM, Miklos Szeredi wrote: On Mon

Re: [RFC] extending splice for copy offloading

On 09/30/2013 10:46 AM, Miklos Szeredi wrote: On Mon, Sep 30, 2013 at 4:41 PM, Ric Wheeler rwhee...@redhat.com 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

Re: [RFC] extending splice for copy offloading

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.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

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 Molnarmi...@kernel.org wrote: * Felipe Contrerasfelipe.contre...@gmail.com wrote: As Linus already pointed out, not everybody has to work with

[LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

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

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

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

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

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

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

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

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

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

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

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

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

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. Ric

[LSF/MM TOPIC] [ATTEND] persistent memory progress, management of storage file systems

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

Re: status of block-integrity

On 12/23/2013 09:35 PM, Martin K. Petersen wrote: Christoph == Christoph Hellwig h...@infradead.org 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

Re: Linux Foundation Technical Advisory Board Elections and Nomination process

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]

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

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 cluster file systems, it's

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

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

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

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

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

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

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/11/2016 12:03 AM, Linus Torvalds wrote: On Thu, Mar 10, 2016 at 6:58 AM, Ric Wheeler <ricwhee...@gmail.com> 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 c

Re: Will Mosix go into the standard kernel?

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

Re: Re-routing packets via netfilter (ip_rt_bug)

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

  1   2   >