Re: Copy/move btrfs volume

[Lubos Kolouch]

Oystein Viggen, Fri, 02 Jul 2010 08:15:03 +0200:

 For btrfs with lots of snapshots, I believe btrfs device add of the
 new device followed by btrfs device remove of the old one would be the
 most convenient.
 
 Øystein

This solution if very elegant and cool - if you can put the discs into one 
computer.

It does not help too much to copy the files over network and preserve the 
snapshots... or can you add like this a network-attached device (sshfs) ?

Lubos

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Atomic replacement of subvolumes is not possible

[C Anthony Risinger]

On Fri, Jul 2, 2010 at 2:38 PM, Goffredo Baroncelli kreij...@gmail.com wrote:
 On Friday, July 02, 2010, Chris Mason wrote:
 On Wed, Jun 30, 2010 at 09:26:11AM -0500, C Anthony Risinger wrote:
 [...]
  what about this:  would it be possible to have TWO subvolumes by
  default?  the regular one (current directory, .):
 
  mount -o subvol=. btrfs_dev /mnt
 
  would behave as it does now.  BUT... there would then be a special,
  permanent (like . is right now) subvol, say parent directory
  (..):
 
  mount -o subvol=.. btrfs_dev /mnt
 
  TWO dots would mount the parent of ., where i could then swap out
  the real default (.).
 
  would that work?

 We do provide a set-default ioctl that can be used to change the default
 for the next mount.   This is pretty close to what you want, let me
 think about ways to make it easier to use.

 -chris

 Hello Chris,

 to me it seems that the Anthony request make sense. And it not so difficult to
 have. We have all the pieces, we need only a policy regarding the subvolume
 use and a bit of glue
 It should be sufficent to replace the standard mkfs.btrfs command with the
 following commands sequence

 # mkfs.btrfs device
 # mount device /mnt/tmp
 # btrfs subvol create /mnt/tmp/__root__
 # btrfs subvol set-default __root__ /mnt/tmp/
 # umount device

 So if an user don't want to care about a subvolume, he simply mount a btrfs
 filesystem without any option. This user will work inside the __root__
 subvolume, where he can create snapshot, subvolume...

 Instead if an user want to play with different root in different subvolumes,
 he have to mount the ., where he can manage the root-subvolume(s) (renaming,
 moving, snapshotting/branching ... ).

 The key is to think the . subvolume only to handling the subvolumes and not
 to storing files. If you don't want to use it, you can simply ignore it,
 because the default is to mount the __root__ subvolume.

i don't want to comment anymore on this thread, as i feel i kind of
hijacked it :-), but what Goffredo has suggested above is a great idea
and would solve my default subvol problems completely.

the real problem is that users are installing into the . subvol not
knowing they cannot easily manipulate the system after that.  as
Goffredo hinted:

The key is to think the . subvolume only to handling the subvolumes
and not to storing files.

if a empty subvol is created, then marked as the new mount default,
users would never know the difference, and integrators like me could
still get underneath to prepare the system for all the cool
distribution-specific btrfs features.

C Anthony
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Btrfs: handle kmalloc() failure in btrfs_file_aio_write()

[Zhang JieJing]

This is the improved of the former patch.

From d9c4cf7dd0e4489a31610e2fb2565ee29f0e4179 Mon Sep 17 00:00:00 2001
From: JieJing.Zhang kzj...@gmail.com
Date: Sun, 4 Jul 2010 01:17:54 +0800
Subject: [PATCH] Btrfs: handle memory alloc failure in btrfs_file_aio_write()

1. kmalloc() should add a check of return valule.

2. In later code it memset zero to the allocated memory,
   so use kzalloc() instead of kmalloc() when allocation is better.

Signed-off-by: JieJing.Zhang kzj...@gmail.com
---
 fs/btrfs/file.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index e354c33..961612c 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -925,7 +925,11 @@ static ssize_t btrfs_file_aio_write(struct kiocb *iocb,
nrptrs = min((iov_iter_count(i) + PAGE_CACHE_SIZE - 1) /
 PAGE_CACHE_SIZE, PAGE_CACHE_SIZE /
 (sizeof(struct page *)));
-   pages = kmalloc(nrptrs * sizeof(struct page *), GFP_KERNEL);
+   pages = kzalloc(nrptrs * sizeof(struct page *), GFP_KERNEL);
+   if (!pages) {
+   ret = -ENOMEM;
+   goto out;
+   }

/* generic_write_checks can change our pos */
start_pos = pos;
@@ -968,7 +972,6 @@ static ssize_t btrfs_file_aio_write(struct kiocb *iocb,
PAGE_CACHE_SHIFT;

WARN_ON(num_pages  nrptrs);
-   memset(pages, 0, sizeof(struct page *) * nrptrs);

ret = btrfs_delalloc_reserve_space(inode, write_bytes);
if (ret)
-- 
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html