On Fri, Jun 03, 2016 at 12:45:51AM +0200, Henk Slager wrote:
> The setup looks all pretty normal and btrfs should be able to handle
> it, but unfortunately your fs is a typical example that one currently
> needs to monitor/tune a btrfs fs for its 'health' in order to keep it
> running longterm.
Wh
New convert introduced simpler chunk/extent allocation algorithm, at the
cost of complex backup superblock migration codes.
Use specially built ext2 images to test if btrfs-convert can convert and
rollback images without problem.
All these special ext2 image have blocks/holes across 2nd btrfs bac
Add support for custom convert test scripts, just like fsck tests.
Instead of generic convert tests, we need more specifically created images
for new convert tests.
This patch provide the needed infrastructure for later convert test
cases.
Signed-off-by: Qu Wenruo
---
v2:
Split test case with
This patch adds mount option 'chunk_width_limit=X', which when set forces
the chunk allocator to use only up to X devices when allocating a chunk.
This may help reduce the seek penalties seen in filesystems with large
numbers of devices.
Signed-off-by: Andrew Armenia
---
fs/btrfs/ctree.h | 3
On Thu, Jun 2, 2016 at 3:55 PM, MegaBrutal wrote:
> 2016-06-02 0:22 GMT+02:00 Henk Slager :
>> What is the kernel version used?
>> Is the fs on a mechanical disk or SSD?
>> What are the mount options?
>> How old is the fs?
>
> Linux 4.4.0-22-generic (Ubuntu 16.04).
> Mechanical disks in LVM.
> Mou
On Thu, Jun 2, 2016 at 9:26 AM, Benedikt Morbach
wrote:
> Hi all,
>
> I've encountered a bug in btrfs-receive. When receiving a certain
> incremental send, it will error with:
>
> ERROR: cannot open
> backup/detritus/root/root.20160524T1800/var/log/journal/9cbb44cf160f4c1089f77e32ed376a0b/user
On Thu, Jun 02, 2016 at 02:17:40PM -0700, Mark Fasheh wrote:
> On Thu, Jun 02, 2016 at 04:56:06PM -0400, Jeff Mahoney wrote:
> > On 6/2/16 3:08 PM, Mark Fasheh wrote:
> > > On Thu, Jun 02, 2016 at 07:07:32PM +0200, David Sterba wrote:
> > >> On Wed, Jun 01, 2016 at 02:15:22PM -0700, Mark Fasheh wro
On Thu, Jun 02, 2016 at 04:56:06PM -0400, Jeff Mahoney wrote:
> On 6/2/16 3:08 PM, Mark Fasheh wrote:
> > On Thu, Jun 02, 2016 at 07:07:32PM +0200, David Sterba wrote:
> >> On Wed, Jun 01, 2016 at 02:15:22PM -0700, Mark Fasheh wrote:
> +/* dynamically allocate and initialize a ref_root */
> >>
On Thu, Jun 2, 2016 at 1:45 PM, Omari Stephens wrote:
> [Note: not on list; please reply-all]
>
> I've read everything I can find about running out of space on btrfs, and it
> hasn't helped. I'm currently dead in the water.
>
> Everything I do seems to make the problem monotonically worse — I tri
On 6/2/16 3:08 PM, Mark Fasheh wrote:
> On Thu, Jun 02, 2016 at 07:07:32PM +0200, David Sterba wrote:
>> On Wed, Jun 01, 2016 at 02:15:22PM -0700, Mark Fasheh wrote:
+/* dynamically allocate and initialize a ref_root */
+static struct ref_root *ref_root_alloc(void)
+{
+ struct
On Thu, Jun 02, 2016 at 01:46:27PM +0800, Lu Fengqi wrote:
>
> At 06/02/2016 05:15 AM, Mark Fasheh wrote:
> >Thanks for trying to fix this problem, comments below.
> >
> >On Wed, Jun 01, 2016 at 01:48:05PM +0800, Lu Fengqi wrote:
> >>Only in the case of different root_id or different object_id, ch
[Note: not on list; please reply-all]
I've read everything I can find about running out of space on btrfs, and
it hasn't helped. I'm currently dead in the water.
Everything I do seems to make the problem monotonically worse — I tried
adding a loopback device to the fs, and now I can't remove
On Thu, Jun 02, 2016 at 07:07:32PM +0200, David Sterba wrote:
> On Wed, Jun 01, 2016 at 02:15:22PM -0700, Mark Fasheh wrote:
> > > +/* dynamically allocate and initialize a ref_root */
> > > +static struct ref_root *ref_root_alloc(void)
> > > +{
> > > + struct ref_root *ref_tree;
> > > +
> > > + re
On Thu, Jun 02, 2016 at 03:22:49PM +0800, Qu Wenruo wrote:
> When copying inode, if there is a file referring part of a hole range,
> convert will fail.
>
> The problem is, when calculating real extent bytenr, it doesn't check if
> the original extent is a hole.
>
> In case the orinal extent is a
On Thu, Jun 02, 2016 at 03:22:50PM +0800, Qu Wenruo wrote:
> New convert introduced simpler chunk/extent allocation algorithm, at the
> cost of complex backup superblock migration codes.
>
> Use specially built ext2 images to test if btrfs-convert can convert and
> rollback images without problem.
On Wed, Jun 01, 2016 at 02:15:22PM -0700, Mark Fasheh wrote:
> > +/* dynamically allocate and initialize a ref_root */
> > +static struct ref_root *ref_root_alloc(void)
> > +{
> > + struct ref_root *ref_tree;
> > +
> > + ref_tree = kmalloc(sizeof(*ref_tree), GFP_KERNEL);
>
> I'm pretty sure we
On Thu, Jun 02, 2016 at 08:38:03AM +0800, Qu Wenruo wrote:
>
>
> At 06/01/2016 09:49 PM, David Sterba wrote:
> > On Wed, Jun 01, 2016 at 04:29:43PM +0800, Qu Wenruo wrote:
> >> New convert doesn't insert holes for superblock migration range.
> >>
> >> Unlike old design, which only relocate 4K(sup
On Thu, Jun 2, 2016 at 6:35 PM, Chris Murphy wrote:
> kernel and btrfs-profs versions?
kernel:
send:4.5.5
receive: 4.5.4
btrfs-progs (both): 4.5.3
--
Benedikt
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.o
On Sun, May 29, 2016 at 06:52:41PM +0800, Qu Wenruo wrote:
> >> + btrfs_set_super_leafsize(super, cfg->nodesize);
> >> + btrfs_set_super_nodesize(super, cfg->nodesize);
> >> + btrfs_set_super_stripesize(super, cfg->stripesize);
> >> + btrfs_set_super_csum_type(super, BTRFS_CSUM_TYPE_CRC32);
> >
On Thu, Jun 2, 2016 at 1:26 AM, Benedikt Morbach
wrote:
>
> Let me know if you need anything else or if I misunderstood the tree
> thing. (I _think_ I can also provide the with-data send, but I'd like
> to take a look at that first ;) )
kernel and btrfs-profs versions?
--
Chris Murphy
--
To uns
On Jun 02 2016, Qu Wenruo wrote:
> At 06/02/2016 11:06 AM, Nikolaus Rath wrote:
>> Hello,
>>
>> For one of my btrfs volumes, btrfsck reports a lot of the following
>> warnings:
>>
>> [...]
>> checking extents
>> bad extent [138477568, 138510336), type mismatch with chunk
>> bad extent [140091392,
On Thu, 2 Jun 2016, Filipe Manana wrote:
On Thu, Jun 2, 2016 at 11:03 AM, Yauhen Kharuzhy
wrote:
On Fri, May 27, 2016 at 10:43:47AM +0100, Filipe Manana wrote:
Hi Filipe,
Hi Scott,
Does your recent patch set (from May 20) address all of these issues?
Yes.
Tested, RAID5/6 still prod
2016-06-02 0:22 GMT+02:00 Henk Slager :
> What is the kernel version used?
> Is the fs on a mechanical disk or SSD?
> What are the mount options?
> How old is the fs?
Linux 4.4.0-22-generic (Ubuntu 16.04).
Mechanical disks in LVM.
Mount: /dev/mapper/centrevg-rootlv on / type btrfs
(rw,relatime,spa
On 2016-06-01 14:30, MegaBrutal wrote:
Hi all,
I have a 20 GB file system and df says I have about 2,6 GB free space,
yet I can't do anything on the file system because I get "No space
left on device" errors. I read that balance may help to remedy the
situation, but it actually doesn't.
Some d
On Wed, Jun 1, 2016 at 5:39 AM, Zygo Blaxell
wrote:
> On Thu, May 05, 2016 at 12:23:49AM -0400, Zygo Blaxell wrote:
>> During a mount, we start the cleaner kthread first because the transaction
>> kthread wants to wake up the cleaner kthread. We start the transaction
>> kthread next because every
On Thu, Jun 2, 2016 at 11:03 AM, Yauhen Kharuzhy
wrote:
> On Fri, May 27, 2016 at 10:43:47AM +0100, Filipe Manana wrote:
>> > Hi Filipe,
>>
>> Hi Scott,
>>
>> >
>> > Does your recent patch set (from May 20) address all of these issues?
>>
>> Yes.
>
> Tested, RAID5/6 still produces a plenty of 'fai
Hey.
I've lost a bit track recently and the wiki changelog doesn't seem to
contain much about how things went on at the RAID5/6 front... so how're
things going?
Is it already more or less "productively" usable? What's still missing?
Well, you still can't even check for free space.
You ca
On Fri, May 27, 2016 at 10:43:47AM +0100, Filipe Manana wrote:
> > Hi Filipe,
>
> Hi Scott,
>
> >
> > Does your recent patch set (from May 20) address all of these issues?
>
> Yes.
Tested, RAID5/6 still produces a plenty of 'failed to rebuild valid
logical NN" messages after two consecutive
On Thu, Jun 02, 2016 at 11:24:45AM +0200, Gerald Hopf wrote:
>
> >Hey.
> >
> >I've lost a bit track recently and the wiki changelog doesn't seem to
> >contain much about how things went on at the RAID5/6 front... so how're
> >things going?
> >
> >Is it already more or less "productively" usable? W
Hey.
I've lost a bit track recently and the wiki changelog doesn't seem to
contain much about how things went on at the RAID5/6 front... so how're
things going?
Is it already more or less "productively" usable? What's still missing?
Well, you still can't even check for free space.
~ # btrfs
Signed-off-by: Satoru Takeuchi
---
btrfs-crc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/btrfs-crc.c b/btrfs-crc.c
index c2b5f00..d433ff3 100644
--- a/btrfs-crc.c
+++ b/btrfs-crc.c
@@ -69,12 +69,14 @@ int main(int argc, char **argv)
str = argv[optind];
- If -c is set, filename argument is ignored.
- Describe about -h option
Signed-off-by: Satoru Takeuchi
---
btrfs-crc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/btrfs-crc.c b/btrfs-crc.c
index 55a4c61..c2b5f00 100644
--- a/btrfs-crc.c
+++ b/btrfs-crc.c
@@ -26,10 +2
Usage is only printed if -h option is set. However it's nice to
do it when wrong option is set or the number of argument is wrong.
Signed-off-by: Satoru Takeuchi
---
btrfs-crc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/btrfs-crc.c b/btrfs-crc.c
index 86dfe0
It's a binary built from btrfs-crc.c
Signed-off-by: Satoru Takeuchi
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index a27cb0d..aaf9702 100644
--- a/.gitignore
+++ b/.gitignore
@@ -33,6 +33,7 @@ btrfs-zero-log
btrfs-corrupt-block
btrfs-select-supe
Remove the following build error.
$ make btrfs-crc
[CC] btrfs-crc.o
[LD] btrfs-crc
btrfs-crc.o: In function `usage':
/home/sat/src/btrfs-progs/btrfs-crc.c:26: multiple definition of `usage'
help.o:/home/sat/src/btrfs-progs/help.c:
Hi all,
I've encountered a bug in btrfs-receive. When receiving a certain
incremental send, it will error with:
ERROR: cannot open
backup/detritus/root/root.20160524T1800/var/log/journal/9cbb44cf160f4c1089f77e32ed376a0b/user-1000.journal:
No such file or directory
even though that path exist
When copying inode, if there is a file referring part of a hole range,
convert will fail.
The problem is, when calculating real extent bytenr, it doesn't check if
the original extent is a hole.
In case the orinal extent is a hole, we still calculate bytenr using
file_pos - found_extent_file_pos,
New convert introduced simpler chunk/extent allocation algorithm, at the
cost of complex backup superblock migration codes.
Use specially built ext2 images to test if btrfs-convert can convert and
rollback images without problem.
All these special ext2 image have blocks across 2nd btrfs backup su
38 matches
Mail list logo