[PATCH 1/3] fs: allow short direct-io reads to be completed via buffered IO

This is similar to what already happens in the write case. If we have a short read while doing O_DIRECT, instead of just returning, fallthrough and try to read the rest via buffered IO. BTRFS needs this because if we encounter a compressed or inline extent during DIO, we need to fallback on

[PATCH 2/3] direct-io: add a hook for the fs to provide its own submit_bio function

Because BTRFS can do RAID and such, we need our own submit hook so we can setup the bio's in the correct fashion, and handle checksum errors properly. So there are a few changes here 1) The submit_io hook. This is straightforward, just call this instead of submit_bio. 2) Honor the boundary

[PATCH 3/3] Btrfs: add basic DIO read support

This provides basic DIO support for reads only. It does not do any of the work to recover from mismatching checksums, that will come later. A few design changes have been made from Jim's code (sorry Jim!) 1) Use the generic direct-io code. Jim originally re-wrote all the generic DIO code in

Re: raild[56] again

On Mon, 2010-05-03 at 22:02 +0200, Roy Sigurd Karlsbakk wrote: Is raid[56] coming to btrfs? There was some talk about it a year back or so, but I haven't seen anything yet Um, there was some talk about it about four days ago. You even participated in that thread! As it stands, it has the

Re: raild[56] again

On Tue, May 04, 2010 at 04:09:09PM +0100, David Woodhouse wrote: On Mon, 2010-05-03 at 22:02 +0200, Roy Sigurd Karlsbakk wrote: Is raid[56] coming to btrfs? There was some talk about it a year back or so, but I haven't seen anything yet Um, there was some talk about it about four days

Re: [PATCH 1/3] fs: allow short direct-io reads to be completed via buffered IO

On Tue, May 04, 2010 at 10:14:18AM +1000, Dave Chinner wrote: On Mon, May 03, 2010 at 01:27:02PM -0400, Josef Bacik wrote: This is similar to what already happens in the write case. If we have a short read while doing O_DIRECT, instead of just returning, fallthrough and try to read the

TRIM + RAID Support?

As I understand it, hardware RAID controllers do not pass the TRIM command to it's disks; btrfs deals with the disk directly, supports TRIM, and supports RAID. I have seen no explicit mention of being able to combine RAID and TRIM support using btrfs with independent disks so I'm asking: When

Re: TRIM + RAID Support?

On Tue, May 04, 2010 at 03:53:17PM +, Justin wrote: As I understand it, hardware RAID controllers do not pass the TRIM command to it's disks; btrfs deals with the disk directly, supports TRIM, and supports RAID. I have seen no explicit mention of being able to combine RAID and TRIM

Re: TRIM + RAID Support?

Awesome. Has there been a lot of testing with RAID + TRIM setups? -- Original Message -- From: Josef Bacik jo...@redhat.com To: Justin yoost...@netzero.com Cc: linux-btrfs@vger.kernel.org Subject: Re: TRIM + RAID Support? Date: Tue, 4 May 2010 11:58:35 -0400 On Tue, May 04, 2010

[PATCH 2/2] Fix version.sh to work with dash

--- fs/btrfs/version.h |6 +++--- fs/btrfs/version.sh | 16 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/fs/btrfs/version.h b/fs/btrfs/version.h index 9bf3946..12f7e5c 100644 --- a/fs/btrfs/version.h +++ b/fs/btrfs/version.h @@ -1,4 +1,4 @@ -#ifndef

[PATCH 1/2] Change version.sh from last tag and hash to output last commit date and hash

The btrfs git repo doesn't have all of the tags from the base 2.6.32 kernel it's currently based upon and the btrfs module is regularly compiled against other kernels so this changes the version to be based upon the date and hash of the latest commit instead which is more relevant to most people

Re: [PATCH 2/2] Fix version.sh to work with dash

Please ignore this patch, I will resend a fixed one. On Tue, May 4, 2010 at 9:12 AM, Mike Fedyk mfe...@mikefedyk.com wrote: ---  fs/btrfs/version.h  |    6 +++---  fs/btrfs/version.sh |   16  2 files changed, 11 insertions(+), 11 deletions(-) diff --git

[PATCH v2 1/2] Change version.sh from last tag and hash to output last commit date and hash

The btrfs git repo doesn't have all of the tags from the base 2.6.32 kernel it's currently based upon and the btrfs module is regularly compiled against other kernels so this changes the version to be based upon the date and hash of the latest commit instead which is more relevant to most people

[PATCH v2 2/2] Fix version.sh to work with dash

--- fs/btrfs/version.sh | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/fs/btrfs/version.sh b/fs/btrfs/version.sh index a4576f2..d87daf4 100755 --- a/fs/btrfs/version.sh +++ b/fs/btrfs/version.sh @@ -1,4 +1,4 @@ -#!/bin/bash +#!/bin/sh # #

Re: Re: Segmentation fault on partition mount

Please fix this bug (SEGFAULT), I can't access to my partition. Image of partition you can download here: http://narod.ru/disk/20400152000/btrfs_dump.z.html kernel BUG at fs/btrfs/tree-log.c:809! invalid opcode: [#1] PREEMPT SMP last sysfs file:

Re: [PATCH 1/3] fs: allow short direct-io reads to be completed via buffered IO

On Tue, May 04, 2010 at 11:27:50AM -0400, Josef Bacik wrote: On Tue, May 04, 2010 at 10:14:18AM +1000, Dave Chinner wrote: On Mon, May 03, 2010 at 01:27:02PM -0400, Josef Bacik wrote: This is similar to what already happens in the write case. If we have a short read while doing

btrfs testing

I ahve been using btrfs as my primary root and home partitions for a few mo enths now, and so far that is going well. I run Arch Linux with the latest Linus git kernels and use the latest btrfs-progs-unstable git trees to manage my btrfs filesystems. My filesystem latout consists of a single

Re: Re: Segmentation fault on partition mount

Thanks all, I found the solution: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg04275.html 1). Apply patch to the kernel source 2). mount -t btrfs -o subvol=/dev/sda5,danger_del_log_tree /dev/sda5 /mount/point 3). mount as usual Please fix this bug (SEGFAULT), I can't access to my