On May 13, 2014, at 7:57 PM, David Brown dav...@davidb.org wrote:
On Tue, May 13, 2014 at 08:44:44PM -0300, Bernardo Donadio wrote:
Hi!
I'm trying to do a send/receive of a snapshot between two disks on Fedora 20
with Linux 3.15-rc5 (and also tried with 3.14 and 3.11) and SELinux
On May 13, 2014, at 9:16 PM, Bernardo Donadio bcdona...@gmail.com wrote:
On 05/13/2014 10:57 PM, David Brown wrote:
$ selinuxenabled; echo $?
It does return '1'. I know SELinux is disabled because I can't boot with it
on (and I have no fucking clue why).
What exactly is the error
On 05/14/2014 09:18 AM, Eric Sandeen wrote:
Allow the specification of the filesystem UUID at mkfs time.
(Implemented only for mkfs.btrfs, not btrfs-convert).
Just out of curiosity, this option is used for what kind of use case?
I notice Ext4 also has this option.:-)
Signed-off-by: Eric
Hello Wang,
sure will do. Thanks for the comments.
Anand
On 13/05/14 17:17, Wang Shilong wrote:
Hello Anand,
I agree we can export @total_devices to fix 'btrfs file show' problem.
This patch addressed two problem, it is better to split it into two
patches.
Could you please resend the
On Wed, May 14, 2014 at 09:49:48AM +0100, Astro Xe wrote:
The content of the FAQ How much space will I get with my multi-device
configuration?
(https://btrfs.wiki.kernel.org/index.php/FAQ#How_much_space_will_I_get_with_my_multi-device_configuration.3F)
is currently wrong. The usable space
Got this soon after boot:
[ 720.086389] INFO: task pidgin:11330 blocked for more than 120 seconds.
[ 720.086402] Not tainted 3.15.0-rc5-amd64-i915-preempt-20140216s1 #1
[ 720.086406] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this
message.
[ 720.086411] pidgin D
On 14/05/14 09:31, Wang Shilong wrote:
On 05/14/2014 09:18 AM, Eric Sandeen wrote:
Allow the specification of the filesystem UUID at mkfs time.
(Implemented only for mkfs.btrfs, not btrfs-convert).
Just out of curiosity, this option is used for what kind of use case?
I notice Ext4 also has
On 03/24/2014 07:58 PM, Jeff Mahoney wrote:
The BTRFS_IOC_SNAP_CREATE_V2 ioctl is limited by requiring that a file
descriptor be passed in order to create the snapshot. This means that
snapshots may only be created of trees that are available in the mounted
namespace. We have a need to create
On 05/12/2014 01:18 PM, David Sterba wrote:
On Mon, May 12, 2014 at 11:00:23PM +0800, Liu Bo wrote:
On Thu, May 08, 2014 at 07:16:19PM -0400, Zach Brown wrote:
uncompress_inline() is silently dropping an error from
btrfs_decompress() after testing it and zeroing the page that was
supposed to
Scott Middleton posted on Mon, 12 May 2014 20:27:13 +0800 as excerpted:
Hi Everyone
History:
I just recently discovered BtrFS. Well really only just started reading
a lot about it. Starting with blogs by Jim Salters and Marc Merlin. So,
thanks for those blogs guys.
This also introduced
On Tue, May 13, 2014 at 09:11:34PM +0100, Filipe David Manana wrote:
Is there anything you'd like from the subvolumes on the source that
btrfs cannot process and that I'm going to delete so that I can start
syncing back from the SSD to the HDD?
For the issue you had with send sending
On 5/14/14, 2:31 AM, Wang Shilong wrote:
On 05/14/2014 09:18 AM, Eric Sandeen wrote:
Allow the specification of the filesystem UUID at mkfs time.
(Implemented only for mkfs.btrfs, not btrfs-convert).
Just out of curiosity, this option is used for what kind of use case?
I notice Ext4 also has
On 14/05/14 08:31, Wang Shilong wrote:
On 05/14/2014 09:18 AM, Eric Sandeen wrote:
Allow the specification of the filesystem UUID at mkfs time.
(Implemented only for mkfs.btrfs, not btrfs-convert).
Just out of curiosity, this option is used for what kind of use case?
I notice Ext4 also has
On Tue, May 13, 2014 at 10:01:02PM +0100, Filipe David Borba Manana wrote:
When running send, if an inode only has extended reference items
associated to it and no regular references, send.c:get_first_ref()
was incorrectly assuming the reference it found was of type
BTRFS_INODE_REF_KEY due to
Brendan Hide posted on Wed, 14 May 2014 14:25:22 +0200 as excerpted:
On 14/05/14 09:31, Wang Shilong wrote:
On 05/14/2014 09:18 AM, Eric Sandeen wrote:
Allow the specification of the filesystem UUID at mkfs time.
(Implemented only for mkfs.btrfs, not btrfs-convert).
Just out of curiosity,
So, I had btrfs_pool1 that was trashed/lost as discussed here recently.
I did btrfs send btrfs_pool2/root_ro.date | btrfs receive /mnt/btrfs_pool1
Then btrfs subvolume snapshot root_ro.date root
Now, after I delete root_ro.date on btrfs_pool1, shouldn't root become a
parent subvolume?
Right
On Fri, May 09, 2014 at 05:15:08PM -0400, Zach Brown wrote:
--- a/fs/btrfs/zlib.c
+++ b/fs/btrfs/zlib.c
@@ -136,7 +136,7 @@ static int zlib_compress_pages(struct list_head *ws,
if (workspace-def_strm.total_in 8192
workspace-def_strm.total_in
Hi Eric,
On 05/14/2014 03:18 AM, Eric Sandeen wrote:
Allow the specification of the filesystem UUID at mkfs time.
I suggest to add some warning when this options is used, because the behavior
could be very different than the one expected.
I suspect that BTRFS tracks the filesystem by UUID and
On 5/14/14, 9:39 AM, Goffredo Baroncelli wrote:
Hi Eric,
On 05/14/2014 03:18 AM, Eric Sandeen wrote:
Allow the specification of the filesystem UUID at mkfs time.
I suggest to add some warning when this options is used, because the
behavior could be very different than the one expected.
On Wed, 2014-05-14 at 14:25 +0200, Brendan Hide wrote:
On 14/05/14 09:31, Wang Shilong wrote:
On 05/14/2014 09:18 AM, Eric Sandeen wrote:
Allow the specification of the filesystem UUID at mkfs time.
(Implemented only for mkfs.btrfs, not btrfs-convert).
Just out of curiosity, this option
On Wed, 2014-05-14 at 16:39 +0200, Goffredo Baroncelli wrote:
Hi Eric,
On 05/14/2014 03:18 AM, Eric Sandeen wrote:
Allow the specification of the filesystem UUID at mkfs time.
I suggest to add some warning when this options is used, because the behavior
could be very different than the
On 05/14/2014 04:41 PM, Eric Sandeen wrote:
I am not against this option; I am suggesting to add a explicit
warning to the user about the risk of doing that, both on the man
pages and into the program. The warning should say that this option
is only for testing. Better ask for a confirmation
On Wed, May 14, 2014 at 09:41:19AM -0500, Eric Sandeen wrote:
I am not against this option; I am suggesting to add a explicit
warning to the user about the risk of doing that, both on the man
pages and into the program. The warning should say that this option
is only for testing. Better
Allow the specification of the filesystem UUID at mkfs time.
Non-unique unique IDs are rejected.
(Implemented only for mkfs.btrfs, not btrfs-convert).
Signed-off-by: Eric Sandeen sand...@redhat.com
---
V2: reject non-unique unique IDs.
diff --git a/btrfs-convert.c b/btrfs-convert.c
index
Hi
I left this for a couple days hoping someone else with a more directly
similar use-case would answer, but none so far, so I'll give it a go...
Thanks for getting back to me mate!
First some general boilerplate. Btrfs is still under heavy development
and keeping current with
Thanks for adding the uuid uniqueness check, that was my major
objection for previous patch iterations,
http://www.spinics.net/lists/linux-btrfs/msg30572.html
we can now use it for convert as well (to generate or copy the uuid).
On Wed, May 14, 2014 at 10:35:05AM -0500, Eric Sandeen wrote:
@@
On 5/14/14, 11:01 AM, David Sterba wrote:
Thanks for adding the uuid uniqueness check, that was my major
objection for previous patch iterations,
http://www.spinics.net/lists/linux-btrfs/msg30572.html
Ah, thanks, I didn't know about that history, I'm sorry.
I'm not sure if my
On 05/14/2014 06:01 PM, David Sterba wrote:
On Wed, May 14, 2014 at 10:35:05AM -0500, Eric Sandeen wrote:
@@ -125,7 +154,19 @@ int make_btrfs(int fd, const char *device, const char
*label,
memset(super, 0, sizeof(super));
num_bytes = (num_bytes / sectorsize) * sectorsize;
-
Allow the specification of the filesystem UUID at mkfs time.
Non-unique unique IDs are rejected. This includes attempting
to re-mkfs with the same UUID; if you really want to do that,
you can mkfs with a new UUID, then re-mkfs with the one you
wanted. ;)
(Implemented only for mkfs.btrfs, not
On Wed, Apr 30, 2014 at 02:31:18PM +0100, Frank Kingswood wrote:
Device size:10.00GiB
FS occuppied:5.00GiB
I found a bit unclear the FS occupied terms.
We're running out of terms to describe and distinguish the space that
the filesystem uses.
'occupied'
On May 14, 2014, at 7:50 AM, Marc MERLIN m...@merlins.org wrote:
So, I had btrfs_pool1 that was trashed/lost as discussed here recently.
I did btrfs send btrfs_pool2/root_ro.date | btrfs receive /mnt/btrfs_pool1
Then btrfs subvolume snapshot root_ro.date root
Now, after I delete
The term has not seen an agreement and we don't want to change it once
it's in non-development branches or even released.
Discussion under the patch:
http://thread.gmane.org/gmane.comp.file-systems.btrfs/34627
Signed-off-by: David Sterba dste...@suse.cz
---
Some variant based on of the terms:
On 2014-05-11 16:19, Hugo Mills wrote:
On Tue, May 13, 2014 at 10:16:59AM +0200, laie wrote:
On 2014-05-09 20:01, Hugo Mills wrote:
On Fri, May 09, 2014 at 06:58:27PM +0100, Hugo Mills wrote:
On Fri, May 09, 2014 at 08:02:45PM +0200, laie wrote:
Now I'm looking for a way to tell btrfs to
On Wed, May 14, 2014 at 08:43:41PM +0200, laie wrote:
On 2014-05-11 16:19, Hugo Mills wrote:
On Tue, May 13, 2014 at 10:16:59AM +0200, laie wrote:
On 2014-05-09 20:01, Hugo Mills wrote:
On Fri, May 09, 2014 at 06:58:27PM +0100, Hugo Mills wrote:
On Fri, May 09, 2014 at 08:02:45PM +0200, laie
On 2014-05-14 20:44, Hugo Mills wrote:
On Wed, May 14, 2014 at 08:43:41PM +0200, laie wrote:
On 2014-05-11 16:19, Hugo Mills wrote:
On Tue, May 13, 2014 at 10:16:59AM +0200, laie wrote:
On 2014-05-09 20:01, Hugo Mills wrote:
On Fri, May 09, 2014 at 06:58:27PM +0100, Hugo Mills wrote:
On Fri,
On Wed, May 14, 2014 at 08:28:30AM -0400, Chris Mason wrote:
I think Filipe fixed this one:
https://patchwork.kernel.org/patch/4143821/
I applied this patch, and I don't have the same deadlock anymore, but
legolas:/mnt/btrfs_pool1# btrfs-subvolume-backup --init -k 5 var
/mnt/btrfs_pool2/
On 05/14/2014 07:39 PM, Eric Sandeen wrote:
Allow the specification of the filesystem UUID at mkfs time.
Non-unique unique IDs are rejected. This includes attempting
to re-mkfs with the same UUID; if you really want to do that,
you can mkfs with a new UUID, then re-mkfs with the one you
On 5/14/14, 5:04 PM, Goffredo Baroncelli wrote:
On 05/14/2014 07:39 PM, Eric Sandeen wrote:
Allow the specification of the filesystem UUID at mkfs time.
Non-unique unique IDs are rejected. This includes attempting
to re-mkfs with the same UUID; if you really want to do that,
you can mkfs
On May 14, 2014, at 2:55 PM, Marc MERLIN m...@merlins.org wrote:
INFO: task btrfs:13329 blocked for more than 120 seconds.
Pretty much anytime blocked for more than 120 seconds is reported, devs ask for
sysrq-w. Typically that translates into three steps:
echo 1 /proc/sys/kernel/sysrq
echo
It turns out that the primary 64K Boot Area A is too small for some
applications and/or some architectures.
When I discussed this with Chris Mason, he pointed out that the area
beyond the superblock is also unused, up until at least the megabyte
point (from my reading of the mkfs code, it is
From: Wang Shilong wangsl.f...@cn.fujitsu.com
While running balance, scrub, fsstress concurrently we hit the
following kernel crash:
[56561.448845] BTRFS info (device sde): relocating block group 11005853696
flags 132
[56561.524077] BUG: unable to handle kernel NULL pointer dereference at
Add '-h' option for help for super-recover,
update the manpage at the same time.
---
Documentation/btrfs-rescue.txt | 2 ++
cmds-rescue.c | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/btrfs-rescue.txt b/Documentation/btrfs-rescue.txt
index
The btrfs-rescue accepts exactly one arg for both
chunk-recover super-recover, use check_argc_exact clearly.
---
cmds-rescue.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmds-rescue.c b/cmds-rescue.c
index 9491d0c..3629141 100644
--- a/cmds-rescue.c
+++
On Wed, 2014-04-02 at 16:54 +0800, Gui Hecheng wrote:
For modern filesystems such as btrfs, t/p/e size level operations
are common.
add size unit t/p/e parsing to memparse
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
changelog
v1-v2: replace kilobyte with kibibyte, and
44 matches
Mail list logo
