Hi Mark,
A week ago I posted a patch to move fs/btrfs/ioctl.h to
include/uapi/linux/btrfs.h in the kernel tree:
http://thread.gmane.org/gmane.comp.file-systems.btrfs/22763/focus=22764
My main motivation was to export the kernel headers with the ioctl
constants/structs so that other programs may u
Thank you, that makes a lot of sense :)
It's been a good day, I've learnt something :)
On Tue, Feb 5, 2013 at 4:29 PM, Chester wrote:
> The last argument should be the directory you want to clone into. Use
> '-b ' to specify the branch you want to clone. I'm pretty sure
> you've compiled just th
The last argument should be the directory you want to clone into. Use
'-b ' to specify the branch you want to clone. I'm pretty sure
you've compiled just the master branch of both linux-btrfs and
btrfs-progs.
On Mon, Feb 4, 2013 at 8:59 PM, Gareth Pye wrote:
> I felt like having a small play with
I felt like having a small play with this stuff, as I've been wanting
it for so long :)
But apparently I've made some incredibly newb error.
I used the following two lines to check out the code:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
raid56-experimental
git
Also, a 2-member raid5 or 3-member raid6 are a raid1 and can be treated as such.
Chris Mason wrote:
>On Mon, Feb 04, 2013 at 02:42:24PM -0700, H. Peter Anvin wrote:
>> @@ -1389,6 +1392,14 @@ int btrfs_rm_device(struct btrfs_root *root,
>char
>> *device_path)
>> }
>> btrfs_dev_replace_u
On Mon, Feb 04, 2013 at 02:42:24PM -0700, H. Peter Anvin wrote:
> @@ -1389,6 +1392,14 @@ int btrfs_rm_device(struct btrfs_root *root, char
> *device_path)
> }
> btrfs_dev_replace_unlock(&root->fs_info->dev_replace);
>
> + if ((all_avail & (BTRFS_BLOCK_GROUP_RAID5 |
> +
On Wed, 30 Jan 2013, Josef Bacik wrote:
> On Wed, Jan 30, 2013 at 11:30:49AM -0700, Mike Lowe wrote:
> > I've been running rsync against a rbd device backed by btrfs filesystems
> > that are about 11% full for about 45 minutes before I checked and noticed
> > the printk message. That was the fir
On Saturday 02 February 2013, Chris Mason wrote:
> > Feb 1 22:57:37 localhost kernel: [ 8561.599482] Kernel BUG at
> > a01fdcf7 [verbose debug info unavailable]
>
> > Jan 14 19:18:42 localhost kernel: [1060055.746373] btrfs csum failed ino
> > 15619835 off 454656 csum 2755731641 privat
@@ -1389,6 +1392,14 @@ int btrfs_rm_device(struct btrfs_root *root, char
*device_path)
}
btrfs_dev_replace_unlock(&root->fs_info->dev_replace);
+ if ((all_avail & (BTRFS_BLOCK_GROUP_RAID5 |
+ BTRFS_BLOCK_GROUP_RAID6) && num_devices <= 3)) {
+
On Mon, Feb 04, 2013 at 04:48:56PM +0100, David Sterba wrote:
> On Wed, Jan 30, 2013 at 02:43:41PM -0800, Mark Fasheh wrote:
> > @@ -4570,6 +4605,11 @@ long btrfs_ioctl_send(struct file *mnt_file, void
> > __user *arg_)
> > INIT_RADIX_TREE(&sctx->name_cache, GFP_NOFS);
> > INIT_LIST_HEAD(&
fd53de4d Drop bit-radix.[ch] files
removed the files from the Makefile, but not the files themselves.
Signed-off-by: Eric Sandeen
---
bit-radix.c | 211
bit-radix.h | 33 -
2 files changed, 244 deletions(-)
diff --git a/bi
On Sun, Feb 03, 2013 at 04:37:58PM -0700, "Piotr Pawłow" wrote:
> Hello,
>
> 1 week ago I bought a new 2TB hard drive, created 1 partition on the whole
> disk, and created root and swap LVM volumes on it. I formatted root to
> btrfs with default options, except meta-data profile which I set to
> "
On 2/3/13 8:39 PM, Miao Xie wrote:
> Hi, Eric
>
> I want to send out my fix patch, but Could I add your Signed-off-by?
> because you found the key to solving the problem.
I don't know if a signed-off-by chain is the right approach, but
don't worry about it. You can mention my first patch in the
On Mon, Feb 04, 2013 at 02:08:01AM -0700, Moshe wrote:
> Hello,
>
> If I write large sequential file on snapshot, then create another snapshot,
> overwrite file with small amount of data and delete first snapshot, second
> snapshot has very large data extent and only small part of it is used.
>
On Sun, Feb 03, 2013 at 05:19:29AM -0700, Radek Machulka wrote:
> Hi guys,
>
> my computer suddenly failed to boot. It seams that it is unable to mount
> /home which is btrfs. Here are the messages I get during the boot (the
> relevant part; hopefully):
>
> Feb 02 13:59:58 Edge kernel: kernel BUG
From: Eric Sandeen
print more informative error when we fail to open a device
If open() fails, we should let the user know why it failed.
Signed-off-by: Eric Sandeen
Signed-off-by: Gene Czarcinski
---
utils.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/utils.c b/uti
I believe that this patch may have been lost in the noise and I felt
it made a very small but meaningful change so I shuffled some
test around and made sure it applied to integration-20120201
This patch simply prints more informative message when
we fail to open a device.
Eric Sandeen (1):
Btrf
On Wed, Jan 30, 2013 at 02:43:41PM -0800, Mark Fasheh wrote:
> @@ -4570,6 +4605,11 @@ long btrfs_ioctl_send(struct file *mnt_file, void
> __user *arg_)
> INIT_RADIX_TREE(&sctx->name_cache, GFP_NOFS);
> INIT_LIST_HEAD(&sctx->name_cache_list);
>
> + if (arg->flags & ~BTRFS_SEND_FLA
For write, we also reserve some space for COW blocks during updating
the checksum tree, and we calculate the number of blocks by checking
if the number of bytes outstanding that are going to need csums needs
one more block for csum.
When we add these checksum into the checksum tree, we use ordered
On Mon, Feb 04, 2013 at 01:37:21PM +0100, Simon Campese wrote:
> Hello,
>
> I've got a quick question: Does btrfs adapt to size changes of the
> underlying block device(s)?
>
> My specific situation is as follows: I've got a luks-volume on which I
> want to put btrfs. If this luks-volume grows in
Hello,
I've got a quick question: Does btrfs adapt to size changes of the
underlying block device(s)?
My specific situation is as follows: I've got a luks-volume on which I
want to put btrfs. If this luks-volume grows in the future (i.e. by
'cryptsetup resize'), will btrfs automatically (and reli
Hello,
situation update: I realized I haven't tried "nospace_cache" yet, even
though I tried "clear_cache". "clear cache" doesn't help at all. On the
other hand, with "nospace_cache":
# mount /dev/hdb -odevice=/dev/hdc,nospace_cache /mnt/test
device label root devid 2 transid 56099 /dev/hdc
devic
Hello,
If I write large sequential file on snapshot, then create another snapshot,
overwrite file with small amount of data and delete first snapshot, second
snapshot has very large data extent and only small part of it is used.
For example if I use following sequence:
mkfs.btrfs /dev/sdn
moun
23 matches
Mail list logo
