Sebastian 'gonX' Jensen | 2 May 07:32 2010
Picon

How to expand a BTRFS partition... backwards

Hey guys,

I kinda figured out the syntax for resizing BTRFS arrays, but is it
possible to use free space that is behind the current BTRFS partition?
I kinda figure it's not, but ideally I'd like it so that there is no
unused disk space on the disk.

My partition setup looks something like this:

Partition 1: 100MB (used)
Partition 2: 256MB (not used, this is what I want to use)
Partition 3: 200GB (used, for BTRFS)
Partition 4: 50GB (not used, but this will be expanded to the current
BTRFS partition)

Also as a last note (just in case I've misunderstood something), to
resize properly, you should first delete the partition using a
partition editor like fdisk, then recreate a new partition with the
same start cylinders as the original setup, but with bigger/later end
cylinders than the original setup, right? Then e.g. btrfsctl -r +45G /
What if I have a RAID-0 array (which I do), which uses the RAID-0
routine by BTRFS (and not mdraid or dmraid). Should I then do a
"btrfsctl -R +(size*disks)G /" or btrfsctl -R +(size of all disks)G
/"?

Regards,
Sebastian J.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Sebastian 'gonX' Jensen | 2 May 08:23 2010
Picon

Re: How to expand a BTRFS partition... backwards

Thanks, I figured that the new btrfs tool would have something easier.
Now I only need to know whether expanding btrfs is also possible
backwards on the harddrive.

Regards,
Sebastian J.

On 2 May 2010 07:50, TAXI <taxi <at> a-city.de> wrote:
> The manpage says:
>       filesystem resize [+/-]<size>[gkm]|max <path>
>              Resize  a filesystem identified by <path>.  The <size>
> parameter
>              specifies the new size of the filesystem.  If the prefix +
> or  -
>              is  present  the  size is increased or decreased by the
> quantity
>              <size>.  If no units are  specified,  the  unit  of  the
> <size>
>              parameter  defaults to bytes. Optionally, the size
> parameter may
>              be suffixed by one of the following the units designators:
>  'K',
>              'M', or 'G', kilobytes, megabytes, or gigabytes, respectively.
>
>              If  'max'  is  passed,  the filesystem will occupy all
> available
>              space on the volume(s).
>
>              The resize command does not manipulate the  size  of
> underlying
(Continue reading)

TAXI | 2 May 10:10 2010
Picon

Re: How to expand a BTRFS partition... backwards

I played a bit with my btrfs partition and btrfs filesystem resize
didn't work.
But I found a commando that worked:
btrfsctl -r max /mnt/btrfs
(yes, on the mounted FS -
http://kerneltrap.org/Linux/Btrfs_Online_Resizing_Ext3_Conversion_and_More )

But I don't know if expanding is possible backwards. I have no free
drive to test.

Am 02.05.2010 08:23, schrieb Sebastian 'gonX' Jensen:
> Thanks, I figured that the new btrfs tool would have something easier.
> Now I only need to know whether expanding btrfs is also possible
> backwards on the harddrive.
> 
> Regards,
> Sebastian J.
> 
> On 2 May 2010 07:50, TAXI <taxi <at> a-city.de> wrote:
>> The manpage says:
>>       filesystem resize [+/-]<size>[gkm]|max <path>
>>              Resize  a filesystem identified by <path>.  The <size>
>> parameter
>>              specifies the new size of the filesystem.  If the prefix +
>> or  -
>>              is  present  the  size is increased or decreased by the
>> quantity
>>              <size>.  If no units are  specified,  the  unit  of  the
>> <size>
>>              parameter  defaults to bytes. Optionally, the size
(Continue reading)

Yan, Zheng | 3 May 04:11 2010
Picon

[PATCH] btrfs: Fix block generation verification race

After the path is released, the generation number got from block
pointer is no long valid. The race may cause disk corruption, because
verify_parent_transid() calls clear_extent_buffer_uptodate() when
generation numbers mismatch.

Signed-off-by: Yan Zheng <zheng.yan <at> oracle.com>
---
diff -urp 1/fs/btrfs/ctree.c 2/fs/btrfs/ctree.c
--- 1/fs/btrfs/ctree.c	2010-04-14 14:49:56.342950744 +0800
+++ 2/fs/btrfs/ctree.c	2010-05-03 09:44:24.426642447 +0800
 <at>  <at>  -1589,7 +1589,7  <at>  <at>  read_block_for_search(struct btrfs_trans
 	btrfs_release_path(NULL, p);

 	ret = -EAGAIN;
-	tmp = read_tree_block(root, blocknr, blocksize, gen);
+	tmp = read_tree_block(root, blocknr, blocksize, 0);
 	if (tmp) {
 		/*
 		 * If the read above didn't mark this buffer up to date,
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Sebastian 'gonX' Jensen | 3 May 05:15 2010
Picon

Re: How to expand a BTRFS partition... backwards

On 2 May 2010 23:09, Mike Fleetwood <mike.fleetwood <at> googlemail.com> wrote:
> On 2 May 2010 06:32, Sebastian 'gonX' Jensen <gonx <at> overclocked.net> wrote:
>> Hey guys,
>>
>> I kinda figured out the syntax for resizing BTRFS arrays, but is it
>> possible to use free space that is behind the current BTRFS partition?
>> I kinda figure it's not, but ideally I'd like it so that there is no
>> unused disk space on the disk.
>>
>> My partition setup looks something like this:
>>
>> Partition 1: 100MB (used)
>> Partition 2: 256MB (not used, this is what I want to use)
>> Partition 3: 200GB (used, for BTRFS)
>> Partition 4: 50GB (not used, but this will be expanded to the current
>> BTRFS partition)
>>
>> Also as a last note (just in case I've misunderstood something), to
>> resize properly, you should first delete the partition using a
>> partition editor like fdisk, then recreate a new partition with the
>> same start cylinders as the original setup, but with bigger/later end
>> cylinders than the original setup, right? Then e.g. btrfsctl -r +45G /
>> What if I have a RAID-0 array (which I do), which uses the RAID-0
>> routine by BTRFS (and not mdraid or dmraid). Should I then do a
>> "btrfsctl -R +(size*disks)G /" or btrfsctl -R +(size of all disks)G
>> /"?
>>
>> Regards,
>> Sebastian J.
>
(Continue reading)

Josef Bacik | 3 May 19:27 2010
Picon

[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 buffered.  If the
extent is compressed we need to read the entire thing into memory and
de-compress it into the users pages.  I have tested this with fsx and everything
works great.  Thanks,

Signed-off-by: Josef Bacik <josef <at> redhat.com>
---
 mm/filemap.c |   23 ++++++++++++++++++-----
 1 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index 140ebda..423b439 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
 <at>  <at>  -1263,7 +1263,7  <at>  <at>  generic_file_aio_read(struct kiocb *iocb, const struct iovec *iov,
 {
 	struct file *filp = iocb->ki_filp;
 	ssize_t retval;
-	unsigned long seg;
+	unsigned long seg = 0;
 	size_t count;
 	loff_t *ppos = &iocb->ki_pos;

 <at>  <at>  -1290,21 +1290,34  <at>  <at>  generic_file_aio_read(struct kiocb *iocb, const struct iovec *iov,
 				retval = mapping->a_ops->direct_IO(READ, iocb,
 							iov, pos, nr_segs);
 			}
(Continue reading)

Josef Bacik | 3 May 19:27 2010
Picon

[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 flag a little more specifically.  BTRFS needs to supply
the _logical_ offset to the map_bh in it's get_block function so when we go to
submit the IO we can look up the right checksum information.  In order for this
to work out, we need to make sure each extent we map through get_block gets sent
individually.  The direct IO code tries to merge things together that appear to
be side by side, but since we are using logical offsets, thats always going to
be the case.  So instead of clearing dio->boundary when we create a new bio,
save it in a local variable, and submit the io if boundary was set.

3) Allow the fs to return -ENOTBLK for reads.  Usually this has only worked for
writes, since writes can fallback onto buffered IO.  But BTRFS needs the option
of falling back on buffered IO if it encounters a compressed extent, since we
need to read the entire extent in and decompress it.  So if we get -ENOTBLK back
from get_block we'll return back and fallback on buffered just like the write
case.

I've tested these changes with fsx and everything seems to work.  Thanks,

Signed-off-by: Josef Bacik <josef <at> redhat.com>
---
 fs/direct-io.c     |   32 ++++++++++++++++++++++++++------
 include/linux/fs.h |   19 ++++++++++++++++---
 2 files changed, 42 insertions(+), 9 deletions(-)
(Continue reading)

Josef Bacik | 3 May 19:28 2010
Picon

[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 order to account for all of BTRFS's oddities, but thanks to that work it
seems like the best bet is to just ignore compression and such and just opt to
fallback on buffered IO.

2) Fallback on buffered IO for compressed or inline extents.  Jim's code did
it's own buffering to make dio with compressed extents work.  Now we just
fallback onto normal buffered IO.

3) Lock the entire range during DIO.  I originally had it so we would lock the
extents as get_block was called, and then unlock them as the endio function was
called, which worked great, but if we ever had an error in the submit_io hook,
we could have locked an extent that would never be submitted for IO, so we
wouldn't be able to unlock it, so this solution fixed that problem and made it a
bit cleaner.

I've tested this with fsx and everything works great.  This patch depends on my
dio and filemap.c patches to work.  Thanks,

Signed-off-by: Josef Bacik <josef <at> redhat.com>
---
 fs/btrfs/ctree.h     |    2 +
 fs/btrfs/file-item.c |   25 +++++-
 fs/btrfs/inode.c     |  208 +++++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 230 insertions(+), 5 deletions(-)

(Continue reading)

Roy Sigurd Karlsbakk | 3 May 22:02 2010
Picon

raild[56] again

Hi all

Is raid[56] coming to btrfs? There was some talk about it a year back or so, but I haven't seen anything yet....

Best regards

roy
--
Roy Sigurd Karlsbakk
(+47) 97542685
roy <at> karlsbakk.net
http://blogg.karlsbakk.net/
--
I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ
for alle pedagoger å unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste
tilfeller eksisterer adekvate og relevante synonymer på norsk.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tomasz Torcz | 3 May 22:27 2010
Picon

Re: raild[56] again

On Mon, May 03, 2010 at 10:02:10PM +0200, Roy Sigurd Karlsbakk wrote:
> Hi all
> 
> Is raid[56] coming to btrfs? There was some talk about it a year back or so, but I haven't seen anything yet....

  Look again, there was an email just few days ago:
3705     Apr 29 David Woodhouse ( 13K) Updating RAID[56] support

--

-- 
Tomasz Torcz              ,,If you try to upissue this patchset I shall be seeking
xmpp: zdzichubg <at> chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton (LKML)


Gmane