On 05/14/2014 03:52 AM, Chris Murphy wrote:
Reverse that. If selinux is disabled, labels can't be set. If not enforcing,
you won't get AVC denials for the vast majority of events, but labels can be
set and e.g. restorecon will still work.
Indeed, enabling SELinux into permissive mode solved t
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
> ---
> changelog
> v1->v2: replace kilobyte with kibibyte, and others
> v2-
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 f
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
+++ b/cmds-rescue
Use enum defined error codes to represent different kinds of errs
for super-recover and chunk-recover.
---
chunk-recover.c | 35 ++---
cmds-rescue.c | 36 --
super-recover.c | 69 -
3 file
When run scrub with balance, sometimes -ENOENT will be returned, since
in scrub_enumerate_chunks() will search dev_extent in *COMMIT_ROOT*, but
btrfs_lookup_block_group() will search block group in *MEMORY*, so if a
chunk is removed but not committed, -ENOENT will be returned.
However, there is no
From: Wang Shilong
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
0078
[56561.524237]
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 act
On Wed, May 14, 2014 at 05:13:20PM -0600, Chris Murphy wrote:
>
> On May 14, 2014, at 2:55 PM, Marc MERLIN 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 transl
On May 14, 2014, at 2:55 PM, Marc MERLIN 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 w > /proc/sysrq
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 c
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 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 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:
O
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:45P
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
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
---
Some variant based on of the terms: occupy, hold, ret
On May 14, 2014, at 7:50 AM, Marc MERLIN 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 root_ro.date on
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 filesys
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 bt
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) * s
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 duplicate-c
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:
> @@
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 espe
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
---
V2: reject non-unique unique IDs.
diff --git a/btrfs-convert.c b/btrfs-convert.c
index a8b2c51..d62d4f8 100644
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. Be
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 confir
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 th
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
On Wed, May 14, 2014 at 12:52:50AM -0600, Chris Murphy wrote:
On May 13, 2014, at 7:57 PM, David Brown 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 tri
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 expec
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 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 <
>
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 now
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
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
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 th
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
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 sendi
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 intr
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
>>> s
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 crea
On 05/14/2014 07:40 AM, Marc MERLIN wrote:
> 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" di
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 thi
Hi
I have started using Btrfs for the first time today. I have created a
RAID 5 Array. Did a mount and created Btrfs on top of it.
I was doing some IO using FIO tool. After 2 tests one of the tests
have got below error.
Console log:
stress: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, io
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
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 sp
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 is the sum of the space of the devices.
I'm using multi-devic
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 patch
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 Sand
50 matches
Mail list logo
