30.06.2018 06:22, Duncan пишет:
> Austin S. Hemmelgarn posted on Mon, 25 Jun 2018 07:26:41 -0400 as
> excerpted:
>
>> On 2018-06-24 16:22, Goffredo Baroncelli wrote:
>>> On 06/23/2018 07:11 AM, Duncan wrote:
waxhead posted on Fri, 22 Jun 2018 01:13:31 +0200 as excerpted:
> According
> No log_root* in the super. So no fsyncing at the time? What was
> happening at the time of the power loss?
That I don't know.
> Pretty weird, all three supers are OK and yet two copies of the fs
> tree are corrupt. Why doesn't it fall back automatically to one of the
> other roots?
>
> You
Hugo Mills posted on Mon, 25 Jun 2018 16:54:36 + as excerpted:
> On Mon, Jun 25, 2018 at 06:43:38PM +0200, waxhead wrote:
> [snip]
>> I hope I am not asking for too much (but I know I probably am), but I
>> suggest that having a small snippet of information on the status page
>> showing a
Austin S. Hemmelgarn posted on Mon, 25 Jun 2018 07:26:41 -0400 as
excerpted:
> On 2018-06-24 16:22, Goffredo Baroncelli wrote:
>> On 06/23/2018 07:11 AM, Duncan wrote:
>>> waxhead posted on Fri, 22 Jun 2018 01:13:31 +0200 as excerpted:
>>>
According to this:
Well, there goes that. After about 18H:
ERROR: extent[156909494272, 55320576] referencer count mismatch (root: 21872,
owner: 374857, offset: 235175936) wanted: 1, have: 1452
backref.c:466: __add_missing_keys: Assertion `ref->root_id` failed, value 0
btrfs(+0x3a232)[0x56091704f232]
On 06/29/2018 08:06 PM, David Sterba wrote:
On Tue, Jun 26, 2018 at 10:42:32PM +0800, Anand Jain wrote:
Last version of the proposed fix is to extend the uuid_mutex over the
whole mount callback and use it around calls to btrfs_scan_one_device.
That way we'll be sure the mount will always
I've got about 1/2 the snapshots and less than 1/10th the data...but
my btrfs check times are much shorter than either: 15 minutes and 65
minutes (lowmem).
[chris@f28s ~]$ sudo btrfs fi us /mnt/first
Overall:
Device size:1024.00GiB
Device allocated: 774.12GiB
Device
On Fri, Jun 29, 2018 at 4:09 PM, marble wrote:
> Hey,
> Thanks for the quick reply :-)
>
>> Is there anything like unexpected power loss happens?
> Power loos may have happened. It was power via a RPi.
>> And would you provide the following data for debugging?
>>
>> # btrfs ins dump-super -fFa
On Fri, Jun 29, 2018 at 11:55 AM, wrote:
> Hello,
>
> I recently was mounting some drives in the free drive bays of my server and
> accidentally removed one of my drives from my raid1 btrfs array. I
> immediately put it back in - but whatever damage that would have caused
> seems to be already
Hey,
Thanks for the quick reply :-)
> Is there anything like unexpected power loss happens?
Power loss may have happened.
> And would you provide the following data for debugging?
>
> # btrfs ins dump-super -fFa /dev/mapper/black
I attached it.
> And further more, what's the device mapper setup
Hey,
Thanks for the quick reply :-)
> Is there anything like unexpected power loss happens?
Power loos may have happened. It was power via a RPi.
> And would you provide the following data for debugging?
>
> # btrfs ins dump-super -fFa /dev/mapper/black
See attachment.
> And further more, what's
On Fri, Jun 29, 2018 at 9:15 AM, james harvey wrote:
> On Thu, Jun 28, 2018 at 6:27 PM, Chris Murphy wrote:
>> And an open question I have about scrub is weather it only ever is
>> checking csums, meaning nodatacow files are never scrubbed, or if the
>> copies are at least compared to each
Hello,
I recently was mounting some drives in the free drive bays of my server
and accidentally removed one of my drives from my raid1 btrfs array. I
immediately put it back in - but whatever damage that would have caused
seems to be already done.
I got these log errors [dmesg -T] and
On 2018-06-29 13:58, james harvey wrote:
On Fri, Jun 29, 2018 at 1:09 PM, Austin S. Hemmelgarn
wrote:
On 2018-06-29 11:15, james harvey wrote:
On Thu, Jun 28, 2018 at 6:27 PM, Chris Murphy
wrote:
And an open question I have about scrub is weather it only ever is
checking csums, meaning
On Fri, Jun 29, 2018 at 1:09 PM, Austin S. Hemmelgarn
wrote:
> On 2018-06-29 11:15, james harvey wrote:
>>
>> On Thu, Jun 28, 2018 at 6:27 PM, Chris Murphy
>> wrote:
>>>
>>> And an open question I have about scrub is weather it only ever is
>>> checking csums, meaning nodatacow files are never
28.06.2018 23:09, Hannes Schweizer пишет:
> Hi,
>
> Here's my environment:
> Linux diablo 4.17.0-gentoo #5 SMP Mon Jun 25 00:26:55 CEST 2018 x86_64
> Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz GenuineIntel GNU/Linux
> btrfs-progs v4.17
>
> Label: 'online' uuid: e4dc6617-b7ed-4dfb-84a6-26e3952c8390
On Fri, Jun 29, 2018 at 12:28:31AM -0700, Marc MERLIN wrote:
> So, I rebooted, and will now run Su's btrfs check without repair and
> report back.
As expected, it will likely still take days, here's the start:
gargamel:~# btrfs check --mode=lowmem -p /dev/mapper/dshelf2
Checking filesystem on
On 2018-06-29 11:15, james harvey wrote:
On Thu, Jun 28, 2018 at 6:27 PM, Chris Murphy wrote:
And an open question I have about scrub is weather it only ever is
checking csums, meaning nodatacow files are never scrubbed, or if the
copies are at least compared to each other?
Scrub never looks
On Fri, Jun 29, 2018 at 10:04:02AM +0200, Lionel Bouton wrote:
> Hi,
>
> On 29/06/2018 09:22, Marc MERLIN wrote:
> > On Fri, Jun 29, 2018 at 12:09:54PM +0500, Roman Mamedov wrote:
> >> On Thu, 28 Jun 2018 23:59:03 -0700
> >> Marc MERLIN wrote:
> >>
> >>> I don't waste a week recreating the many
On Fri, Jun 29, 2018 at 10:57:07AM +0200, David Sterba wrote:
> This is called either at the end of the mount or if the mount fails.
> In both cases, there's nothing running that can use the table so the
> lock is pointless.
And then lockdep says no. The umount path frees the table but there's
On Thu, Jun 28, 2018 at 6:27 PM, Chris Murphy wrote:
> And an open question I have about scrub is weather it only ever is
> checking csums, meaning nodatacow files are never scrubbed, or if the
> copies are at least compared to each other?
Scrub never looks at nodatacow files. It does not
On 29.06.2018 17:29, David Sterba wrote:
> On Fri, Jun 29, 2018 at 12:08:10PM +0300, Nikolay Borisov wrote:
>>> for (i = 0; i < num_pages; i++)
>>> copy_page(page_address(dst->pages[i]),
>>> page_address(src->pages[i]));
>>> diff --git
On Fri, Jun 29, 2018 at 12:08:10PM +0300, Nikolay Borisov wrote:
> > for (i = 0; i < num_pages; i++)
> > copy_page(page_address(dst->pages[i]),
> > page_address(src->pages[i]));
> > diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
> > index
On Tue, Jun 26, 2018 at 05:00:46PM +0300, Nikolay Borisov wrote:
> On 25.06.2018 19:38, David Sterba wrote:
> > There are several WARN_ON calls that catch incrorrect reference counter
> > updates, but this is what the refcount_t does already:
> >
> > * refcount_inc from 0 will warn
> > *
On Fri, Jun 29, 2018 at 09:07:12PM +0800, Qu Wenruo wrote:
> >> @@ -5117,7 +5117,7 @@ void free_extent_buffer(struct extent_buffer *eb)
> >>
> >>spin_lock(>refs_lock);
> >>if (atomic_read(>refs) == 2 &&
> >> - test_bit(EXTENT_BUFFER_DUMMY, >bflags))
> >> +
On 29.06.2018 16:07, Qu Wenruo wrote:
>
>
> On 2018年06月29日 20:46, David Sterba wrote:
>> On Wed, Jun 27, 2018 at 04:38:24PM +0300, Nikolay Borisov wrote:
>>> EXTENT_BUFFER_DUMMY is an awful name for this flag. Buffers which have
>>> this flag set are not in any way dummy. Rather, they are
On 2018年06月29日 20:46, David Sterba wrote:
> On Wed, Jun 27, 2018 at 04:38:24PM +0300, Nikolay Borisov wrote:
>> EXTENT_BUFFER_DUMMY is an awful name for this flag. Buffers which have
>> this flag set are not in any way dummy. Rather, they are private in
>> the sense that are not linked to the
On Fri, 2018-06-29 at 09:10 +0800, Qu Wenruo wrote:
> Maybe it's the old mkfs causing the problem?
> Although mkfs.btrfs added device size alignment much earlier than
> kernel, it's still possible that the old mkfs doesn't handle the
> initial
> device and extra device (mkfs.btrfs will always
Running xfstest on today's misc-next revealed the following lockdep splat
(but the machine didn't lock up):
[ 1477.192040] ==
[ 1477.192226] WARNING: possible circular locking dependency detected
[ 1477.192393] 4.18.0-rc1-nbor #755 Not tainted
On Wed, Jun 27, 2018 at 04:38:24PM +0300, Nikolay Borisov wrote:
> EXTENT_BUFFER_DUMMY is an awful name for this flag. Buffers which have
> this flag set are not in any way dummy. Rather, they are private in
> the sense that are not linked to the global buffer tree. This flag has
> subtle
On 2018年06月29日 19:04, marble wrote:
> Hello,
> I have an external HDD. The HDD contains no partition.
> I use the whole HDD as a LUKS container. Inside that LUKS is a btrfs.
> It's used to store some media files.
> The HDD was hooked up to a Raspberry Pi running up-to-date Arch Linux
> to play
On Wed, Jun 27, 2018 at 04:38:22PM +0300, Nikolay Borisov wrote:
> The purpose of the function is to free all the pages comprising an
> extent buffer. This can be achieved with a simple for loop rather than
> the slitghly more involved 'do {} while' construct. So rewrite the
> loop using a 'for'
On Tue, Jun 26, 2018 at 10:42:32PM +0800, Anand Jain wrote:
> >>> Last version of the proposed fix is to extend the uuid_mutex over the
> >>> whole mount callback and use it around calls to btrfs_scan_one_device.
> >>> That way we'll be sure the mount will always get to the device it
> >>> scanned
On Fri, Jun 29, 2018 at 10:13:44AM +0300, Nikolay Borisov wrote:
> On 29.06.2018 10:11, Anand Jain wrote:
> >
> > On 06/29/2018 01:26 PM, Nikolay Borisov wrote:
> >> Since commit 88c14590cdd6 ("btrfs: use RCU in btrfs_show_devname for
> >> device list traversal") btrfs_show_devname no longer
On 2018-06-29 07:04, marble wrote:
Hello,
I have an external HDD. The HDD contains no partition.
I use the whole HDD as a LUKS container. Inside that LUKS is a btrfs.
It's used to store some media files.
The HDD was hooked up to a Raspberry Pi running up-to-date Arch Linux
to play music from the
Hello,
I have an external HDD. The HDD contains no partition.
I use the whole HDD as a LUKS container. Inside that LUKS is a btrfs.
It's used to store some media files.
The HDD was hooked up to a Raspberry Pi running up-to-date Arch Linux
to play music from the drive.
After disconnecting the
Nikolay Borisov 於 2018-06-29 16:43 寫到:
On 29.06.2018 11:27, Ethan Lien wrote:
We use percpu_counter to reduce lock contention of frequently updated
counter. But the default 32 batch size is suitable only for inc/dec
update, not for sector size update. The end result is we still acquire
spin
On 29.06.2018 11:56, David Sterba wrote:
> Almost all callers pass the start and len as 2 arguments but this is not
> necessary, all the information is provided by the eb. By reordering the
> calls to num_extent_pages, we don't need the local variables with
> start/len.
>
> Reviewed-by:
This is called either at the end of the mount or if the mount fails.
In both cases, there's nothing running that can use the table so the
lock is pointless.
Signed-off-by: David Sterba
---
fs/btrfs/raid56.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/fs/btrfs/raid56.c
Signed-off-by: David Sterba
---
fs/btrfs/raid56.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index f9b349171d61..339cce0878d1 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -170,7 +170,7 @@ static int
Signed-off-by: David Sterba
---
fs/btrfs/raid56.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index f30d847baf07..96a7d3445623 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -162,7 +162,6 @@ static int
There's only one call site of the unlocked helper so it can be folded
into the caller.
Signed-off-by: David Sterba
---
fs/btrfs/raid56.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index
Add fall-back code to catch failure of full_stripe_write. Proper error
handling from inside run_plug would need more code restructuring as it's
called at arbitrary points by io scheduler.
Signed-off-by: David Sterba
---
fs/btrfs/raid56.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
The helper is trivial and marked as deprecated.
Signed-off-by: David Sterba
---
fs/btrfs/check-integrity.c | 2 +-
fs/btrfs/compression.c | 4 ++--
fs/btrfs/extent_io.c | 2 +-
fs/btrfs/inode.c | 2 +-
fs/btrfs/raid56.c | 10 +-
fs/btrfs/scrub.c
The loops iterating eb pages use unsigned long, that's an overkill as
we know that there are at most 16 pages (64k / 4k), and 4 by default
(with nodesize 16k).
Reviewed-by: Nikolay Borisov
Signed-off-by: David Sterba
---
fs/btrfs/extent_io.c | 44 ++--
Almost all callers pass the start and len as 2 arguments but this is not
necessary, all the information is provided by the eb. By reordering the
calls to num_extent_pages, we don't need the local variables with
start/len.
Reviewed-by: Nikolay Borisov
Signed-off-by: David Sterba
---
Add helper that schedules a given function to run on the rmw workqueue.
This will replace several standalone helpers.
Signed-off-by: David Sterba
---
fs/btrfs/raid56.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index
Signed-off-by: David Sterba
---
fs/btrfs/raid56.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index 96a7d3445623..f9b349171d61 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -162,7 +162,6 @@ static int
Remove includes if none of the interfaces and exports is used in the
given source file.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 4
fs/btrfs/dev-replace.c | 5 -
fs/btrfs/disk-io.c | 2 --
fs/btrfs/file.c | 3 ---
fs/btrfs/inode-map.c| 1 -
There are several places when the btrfs inode is converted to the
generic inode, back to btrfs and then passed to btrfs_ino. We can remove
the extra back and forth conversions.
Signed-off-by: David Sterba
---
fs/btrfs/inode.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
Use the helper that's possibly optimized for full page copies.
Signed-off-by: David Sterba
---
fs/btrfs/free-space-cache.c | 4 ++--
fs/btrfs/raid56.c | 12 +---
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c
Functions that get btrfs inode can simply reach the fs_info by
dereferencing the root and this looks a bit more straightforward
compared to the btrfs_sb(...) indirection.
If the transaction handle is available and not NULL it's used instead.
Signed-off-by: David Sterba
---
Minor interface/API and other safe cleanups.
David Sterba (14):
btrfs: simplify some assignments of inode numbers
btrfs: simplify pointer chasing of local fs_info variables
btrfs: use copy_page for copying pages instead of memcpy
btrfs: prune unused includes
btrfs: pass only eb to
On 29.06.2018 11:27, Ethan Lien wrote:
> We use percpu_counter to reduce lock contention of frequently updated
> counter. But the default 32 batch size is suitable only for inc/dec
> update, not for sector size update. The end result is we still acquire
> spin lock for every
We use percpu_counter to reduce lock contention of frequently updated
counter. But the default 32 batch size is suitable only for inc/dec
update, not for sector size update. The end result is we still acquire
spin lock for every percpu_counter_add(). So use customized batch size
for
Hi,
On 29/06/2018 09:22, Marc MERLIN wrote:
> On Fri, Jun 29, 2018 at 12:09:54PM +0500, Roman Mamedov wrote:
>> On Thu, 28 Jun 2018 23:59:03 -0700
>> Marc MERLIN wrote:
>>
>>> I don't waste a week recreating the many btrfs send/receive relationships.
>> Consider not using send/receive, and
On Fri, 29 Jun 2018 00:22:10 -0700
Marc MERLIN wrote:
> On Fri, Jun 29, 2018 at 12:09:54PM +0500, Roman Mamedov wrote:
> > On Thu, 28 Jun 2018 23:59:03 -0700
> > Marc MERLIN wrote:
> >
> > > I don't waste a week recreating the many btrfs send/receive relationships.
> >
> > Consider not using
On Fri, Jun 29, 2018 at 03:20:42PM +0800, Qu Wenruo wrote:
> If certain btrfs specific operations are involved, it's definitely not OK:
> 1) Balance
> 2) Quota
> 3) Btrfs check
Ok, I understand. I'll try to balance almost never then. My problems did
indeed start because I ran balance and it got
On Fri, Jun 29, 2018 at 12:09:54PM +0500, Roman Mamedov wrote:
> On Thu, 28 Jun 2018 23:59:03 -0700
> Marc MERLIN wrote:
>
> > I don't waste a week recreating the many btrfs send/receive relationships.
>
> Consider not using send/receive, and switching to regular rsync instead.
> Send/receive
On 2018年06月29日 14:59, Marc MERLIN wrote:
> On Fri, Jun 29, 2018 at 02:29:10PM +0800, Qu Wenruo wrote:
>>> If --repair doesn't work, check is useless to me sadly.
>>
>> Not exactly.
>> Although it's time consuming, I have manually patched several users fs,
>> which normally ends pretty well.
>
On Thu, 28 Jun 2018 23:59:03 -0700
Marc MERLIN wrote:
> I don't waste a week recreating the many btrfs send/receive relationships.
Consider not using send/receive, and switching to regular rsync instead.
Send/receive is very limiting and cumbersome, including because of what you
described. And
On 29.06.2018 10:11, Anand Jain wrote:
>
> On 06/29/2018 01:26 PM, Nikolay Borisov wrote:
>> Since commit 88c14590cdd6 ("btrfs: use RCU in btrfs_show_devname for
>> device list traversal") btrfs_show_devname no longer takes
>> device_list_mutex. As such the deadlock that 0ccd05285e7f ("btrfs:
On 06/29/2018 01:26 PM, Nikolay Borisov wrote:
Since commit 88c14590cdd6 ("btrfs: use RCU in btrfs_show_devname for
device list traversal") btrfs_show_devname no longer takes
device_list_mutex. As such the deadlock that 0ccd05285e7f ("btrfs: fix
a possible umount deadlock") aimed to fix no
On Mon, Jun 25, 2018 at 07:16:38PM +0200, David Sterba wrote:
> On Mon, May 14, 2018 at 06:35:48PM +0200, David Sterba wrote:
> > On Fri, May 11, 2018 at 01:30:01PM -0700, Omar Sandoval wrote:
> > > On Fri, May 11, 2018 at 09:05:38PM +0100, Al Viro wrote:
> > > > On Thu, May 10, 2018 at 11:30:10PM
On Fri, Jun 29, 2018 at 02:29:10PM +0800, Qu Wenruo wrote:
> > If --repair doesn't work, check is useless to me sadly.
>
> Not exactly.
> Although it's time consuming, I have manually patched several users fs,
> which normally ends pretty well.
Ok I understand now.
> > Agreed, I doubt I have
On Fri, Jun 29, 2018 at 02:32:44PM +0800, Su Yue wrote:
> > > https://github.com/Damenly/btrfs-progs/tree/tmp1
> >
> > Not sure if I undertand that you meant, here.
> >
> Sorry for my unclear words.
> Simply speaking, I suggest you to stop current running check.
> Then, clone above branch to
On 2018年06月29日 14:06, Marc MERLIN wrote:
> On Fri, Jun 29, 2018 at 01:48:17PM +0800, Qu Wenruo wrote:
>> Just normal btrfs check, and post the output.
>> If normal check eats up all your memory, btrfs check --mode=lowmem.
>
> Does check without --repair eat less RAM?
Unfortunately, no.
>
>>
On 06/29/2018 02:10 PM, Marc MERLIN wrote:
On Fri, Jun 29, 2018 at 02:02:19PM +0800, Su Yue wrote:
I have figured out the bug is lowmem check can't deal with shared tree block
in reloc tree. The fix is simple, you can try the follow repo:
https://github.com/Damenly/btrfs-progs/tree/tmp1
On 06/29/2018 02:26 AM, David Sterba wrote:
On Thu, Jun 28, 2018 at 07:22:59PM +0800, Anand Jain wrote:
The circular locking dependency warning occurs at FSSTRESS_PROG.
And in particular at doproc() in xfstests/ltp/fsstress.c, randomly
at any of the command at
opdesc_t
On Fri, Jun 29, 2018 at 02:02:19PM +0800, Su Yue wrote:
> I have figured out the bug is lowmem check can't deal with shared tree block
> in reloc tree. The fix is simple, you can try the follow repo:
>
> https://github.com/Damenly/btrfs-progs/tree/tmp1
Not sure if I undertand that you meant,
On Fri, Jun 29, 2018 at 01:48:17PM +0800, Qu Wenruo wrote:
> Just normal btrfs check, and post the output.
> If normal check eats up all your memory, btrfs check --mode=lowmem.
Does check without --repair eat less RAM?
> --repair should be considered as the last method.
If --repair doesn't
71 matches
Mail list logo
