Add subcommand to get the default subvolume of btrfs filesystem
V2->V3:
* add man page
* based on http://git.darksatanic.net/repo/btrfs-progs-unstable.git
integration-20110705
Reviewed-by: Andreas Philipp
Reviewed-by: Goffredo Baroncelli
Reported-by: Yang, Yi
Signed-off-by: Zhong, Xin
---
> -Original Message-
> From: Goffredo Baroncelli
> [mailto:kreij...@libero.it]
> Sent: Monday, July 11, 2011 8:03 PM
> To: Zhong, Xin
> Cc: linux-btrfs@vger.kernel.org
> Subject: R: [PATCH V2] Btrfs-progs: add "btrfs subvolume get-default"
> subcommand
>
> >Messaggio originale
> >
> -Original Message-
> From: Andreas Philipp [mailto:philipp.andr...@gmail.com]
> Sent: Monday, July 11, 2011 10:11 PM
> To: Zhong, Xin
> Cc: linux-btrfs@vger.kernel.org; Hugo Mills
> Subject: Re: [PATCH V2] Btrfs-progs: add "btrfs subvolume get-default"
> subcommand
>
>
> -BEGIN PG
Thanks.
I don't see reason why this needs another mount switch. This would
fail to start whole system in / parition was btrfs raid1, with no
reason to do so.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordo
dd if=/dev/null of=img5 bs=1 seek=2G
dd if=/dev/null of=img6 bs=1 seek=2G
mkfs.btrfs -d raid1 -m raid1 img5 img6
losetup /dev/loop4 img5
losetup /dev/loop5 img6
btrfs device scan
mount -t btrfs /dev/loop4 dir
umount dir
losetup -d /dev/loop5
mount -t btrfs -o degraded /dev/loop4 dir
umount dir
lose
On 07/11/2011 08:22 PM, krz...@gmail.com wrote:
I wanted to confirm that btrfs will continue to work on raid1 when one
of devices will be gone.
dd if=/dev/null of=img0 bs=1 seek=2G
dd if=/dev/null of=img1 bs=1 seek=2G
mkfs.btrfs -d raid1 -m raid1 img0 img1
losetup /dev/loop1 img0
losetup /dev/lo
I wanted to confirm that btrfs will continue to work on raid1 when one
of devices will be gone.
dd if=/dev/null of=img0 bs=1 seek=2G
dd if=/dev/null of=img1 bs=1 seek=2G
mkfs.btrfs -d raid1 -m raid1 img0 img1
losetup /dev/loop1 img0
losetup /dev/loop2 img1
mkdir dir
mount -t btrfs /dev/loop1 dir
b
On Mon, Jul 11, 2011 at 09:11:24PM +0200, Jan Schmidt wrote:
> On 07/11/2011 08:38 PM, Goffredo Baroncelli wrote:
> > what about generating the man page on the basis of the btrfs help
> > detailed messages ?
> >
> > My idea is the following:
> > before the function source associated to the command
Josef Bacik wrote:
> On 07/11/2011 07:40 AM, Jeremy Sanders wrote:
>> Jeremy Sanders wrote:
>>
>>> Hi - I'm trying btrfs with kernel 2.6.38.8-32.fc15.x86_64 (a Fedora
>>> kernel). I'm just doing a tar-to-tar copy onto the file system with
>>> compress- force=zlib. Here are some traces of the stuc
On Mon, Jul 11, 2011 at 04:29:24PM +0200, Jan Schmidt wrote:
> On 10.07.2011 20:23, Hugo Mills wrote:
> >Yes, this is over three months after the initial posting, but since
> > nobody else has looked at it yet, and the patch is in my integration
> > stack...
>
> ... thanks!
>
> >I've not
OK, here's the remainder of my comments for this file. Not much for
this bit -- just one comment about locking, a reminder, and an
observation.
On Wed, Mar 30, 2011 at 06:53:12PM +0200, Jan Schmidt wrote:
[...]
> +static int _scrub_write_buf(int fd, const void *data, int len)
> +{
> + int
On 07/11/2011 09:11 PM, Jan Schmidt wrote:
> On 07/11/2011 08:38 PM, Goffredo Baroncelli wrote:
>> what about generating the man page on the basis of the btrfs help
>> detailed messages ?
>>
>> My idea is the following:
>> before the function source associated to the command we can put a
>> comment
2011/7/11 João Eduardo Luís :
> Hello.
>
> Am I reading the code the wrong way, or is the 'last_index' variable in
> '__btrfs_buffered_write()' (and previously used in 'btrfs_file_aio_write()')
> irrelevant?
>
> It appears to just be used in 'prepare_pages()', passed as an argument, but
> never
On 07/11/2011 08:38 PM, Goffredo Baroncelli wrote:
> what about generating the man page on the basis of the btrfs help
> detailed messages ?
>
> My idea is the following:
> before the function source associated to the command we can put a
> comment with a detailed help. The comment may be:
>
> [.
Hi, all.
what about generating the man page on the basis of the btrfs help
detailed messages ?
My idea is the following:
before the function source associated to the command we can put a
comment with a detailed help. The comment may be:
[...]
/*** man:btrfs subvolume create
*
* btrfs subvolum
This is the follow up to the patch series
"[PATCH v1 0/2] Btrfs-progs: commands "resolve inode" and "resolve logical"
I chose to change the subject as the command names changed.
Changes v1->v2:
- commands renamed as suggested by Goffredo Baroncelli
- man pages added
The kernel patch series jus
Added "inspect-internal inode-resolve" and "inspect-internal
logical-resolve" to the btrfs(8) man page.
Signed-off-by: Jan Schmidt
---
man/btrfs.8.in | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 84a60c
two new commands that make use of the new path resolving functions
implemented for scrub, doing the resolving in-kernel. the result for both
commands is a list of files belonging to that inode / logical address.
Signed-off-by: Jan Schmidt
---
btrfs-list.c | 35
btrfs.c | 10
split list_subvols to separate functions and allow printing only in the
containing function. lets us make use of those functions when resolving
logical addresses.
Signed-off-by: Jan Schmidt
---
btrfs-list.c | 104 ++---
1 files changed, 69 ins
Hello.
Am I reading the code the wrong way, or is the 'last_index' variable in
'__btrfs_buffered_write()' (and previously used in 'btrfs_file_aio_write()')
irrelevant?
It appears to just be used in 'prepare_pages()', passed as an argument, but
never actually used by this function.
Furthermor
2011-07-11 12:25:51 -0400, Chris Mason:
[...]
> > Also, when I resume the rsync (so it doesn't transfer the
> > already transfered files), it does BUG() again.
>
> Ok, could you please send along the exact rsync command you were
> running?
[...]
I did earlier, but here it is again:
rsync --archi
Excerpts from Stephane Chazelas's message of 2011-07-11 11:35:56 -0400:
> 2011-07-11 11:00:19 -0400, Chris Mason:
> > Excerpts from Stephane Chazelas's message of 2011-07-11 05:01:21 -0400:
> > > 2011-07-10 19:37:28 +0100, Stephane Chazelas:
> > > > 2011-07-10 08:44:34 -0400, Chris Mason:
> > > > [
2011-07-11 11:00:19 -0400, Chris Mason:
> Excerpts from Stephane Chazelas's message of 2011-07-11 05:01:21 -0400:
> > 2011-07-10 19:37:28 +0100, Stephane Chazelas:
> > > 2011-07-10 08:44:34 -0400, Chris Mason:
> > > [...]
> > > > Great, we're on the right track. Does it trigger with mount -o compr
Hi Hubert,
I have to admit I did not recognize this patch but now Hugo is forcing
me to use the "detailed help messages" and I've got an improvement to
suggest:
On 23.01.2011 13:42, Hubert Kario wrote:
> extend the
>
> btrfs --help
>
> command to print detailed help message if availabl
Excerpts from Stephane Chazelas's message of 2011-07-11 05:01:21 -0400:
> 2011-07-10 19:37:28 +0100, Stephane Chazelas:
> > 2011-07-10 08:44:34 -0400, Chris Mason:
> > [...]
> > > Great, we're on the right track. Does it trigger with mount -o compress
> > > instead of mount -o compress_force?
> >
grab_cache_page will use mapping_gfp_mask(), which for all inodes is set to
GFP_HIGHUSER_MOVABLE. So instead use find_or_create_page in all cases where we
need GFP_NOFS so we don't deadlock. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/file.c |3 ++-
fs/btrfs/free-space-cach
On 07/11/2011 07:40 AM, Jeremy Sanders wrote:
> Jeremy Sanders wrote:
>
>> Hi - I'm trying btrfs with kernel 2.6.38.8-32.fc15.x86_64 (a Fedora
>> kernel). I'm just doing a tar-to-tar copy onto the file system with
>> compress- force=zlib. Here are some traces of the stuck processes.
>
> I've mana
On 10.07.2011 20:23, Hugo Mills wrote:
>Yes, this is over three months after the initial posting, but since
> nobody else has looked at it yet, and the patch is in my integration
> stack...
... thanks!
>I've not reviewed the whole thing -- just the "scrub start" code so
> far. I've remove
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Would you mind rebasing your patch on Hugo Mills' integration-branch for
btrfs progs at
http://git.darksatanic.net/repo/btrfs-progs-unstable.git
integration-20110705
since it does not apply on top of all changes which are already there.
Additionally,
On 07/10/2011 08:20 PM, Mitch Harder wrote:
> On Sat, Jul 2, 2011 at 4:25 PM, Josef Bacik wrote:
>> On 07/01/2011 04:39 PM, Josef Bacik wrote:
>>> Hey Chris,
>>>
>>> Since I'm going on vacation next week I wanted to get everything ready for
>>> you
>>> in case you get bored with fsck and want to
2011-07-11 14:39:18 +0200, krz...@gmail.com :
> 2011/7/11 Stephane Chazelas :
[...]
> > See also
> > http://thread.gmane.org/gmane.comp.file-systems.btrfs/9675/focus=9820
> > for a way to transfer btrfs fs.
> >
> > (Add a layer of "copy-on-write" on the original devices (LVM
> > snapshots, nbd/qemu
2011/7/11 Stephane Chazelas :
> 2011-07-11 02:00:51 +0200, krz...@gmail.com :
>> Documentation says that btrfs-image zeros data. Feature request is for
>> disabling this. btrfs-image could be used to copy filesystem to
>> another drive (for example with snapshots, when copying it file by
>> file wo
>Messaggio originale
>Da: xin.zh...@intel.com
>Data: 11/07/2011 10.56
>A:
>Cc:
>Ogg: [PATCH V2] Btrfs-progs: add "btrfs subvolume get-default"
subcommand
>
>Add subcommand to get the default subvolume of btrfs filesystem
>
>Reported-by: Yang, Yi
>Signed-off-by: Zhong, Xin
>---
> btrfs-
Jeremy Sanders wrote:
> Hi - I'm trying btrfs with kernel 2.6.38.8-32.fc15.x86_64 (a Fedora
> kernel). I'm just doing a tar-to-tar copy onto the file system with
> compress- force=zlib. Here are some traces of the stuck processes.
I've managed to reproduce the hang using the latest btrfs from the
On 07/08/2011 09:55 PM, Chris Mason wrote:
Hi everyone,
The for-linus branch of the btrfs-unstable repo:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git for-linus
Has three more fixes. We're fixing oopsen during space balancing (btrfs
filesystem balance /mnt)) and durin
Add subcommand to get the default subvolume of btrfs filesystem
Reported-by: Yang, Yi
Signed-off-by: Zhong, Xin
---
btrfs-list.c | 57 +++--
btrfs.c |3 +++
btrfs_cmds.c | 31 ++-
btrfs_cmds.h |3 ++
2011-07-11 02:00:51 +0200, krz...@gmail.com :
> Documentation says that btrfs-image zeros data. Feature request is for
> disabling this. btrfs-image could be used to copy filesystem to
> another drive (for example with snapshots, when copying it file by
> file would take much longer time or acctual
Add subcommand to get the default subvolume of btrfs filesystem
Reported-by: Yang, Yi
Signed-off-by: Zhong, Xin
---
btrfs-list.c | 60 -
btrfs.c |3 ++
btrfs_cmds.c | 31 +-
btrfs_cmds.h |3 +-
2011-07-10 19:37:28 +0100, Stephane Chazelas:
> 2011-07-10 08:44:34 -0400, Chris Mason:
> [...]
> > Great, we're on the right track. Does it trigger with mount -o compress
> > instead of mount -o compress_force?
> [...]
>
> It does trigger. I get that same "invalid opcode".
>
> BTW, I tried with
On Mon, Jul 11, 2011 at 2:02 PM, Leonidas Spyropoulos
wrote:
> On Mon, Jul 11, 2011 at 7:04 AM, Fajar A. Nugraha wrote:
>> On Mon, Jul 11, 2011 at 5:34 AM, Leonidas Spyropoulos
>> wrote:
>>> So any clues for the intel 320 series? I think it doesn't use compression.
>>
>> At this point your best
On 07/11/2011 06:53 AM, Chris Samuel wrote:
On Mon, 11 Jul 2011 07:59:54 AM Fajar A. Nugraha wrote:
Sandforce-based SSDs have their own way of reducing writes
(e.g. by using internal compression), so you don't have to
do anything special
Not just compression, but also block level de-duplicatio
On Mon, Jul 11, 2011 at 7:04 AM, Fajar A. Nugraha wrote:
> On Mon, Jul 11, 2011 at 5:34 AM, Leonidas Spyropoulos
> wrote:
>> So any clues for the intel 320 series? I think it doesn't use compression.
>
> At this point your best bet is to try it yourself and see. If it
> doesn't result in poor per
42 matches
Mail list logo
