while mounting the device the dmesg is full of:
[ 1320.325147] [] ? kthread_park+0x60/0x60
[ 1440.330008] INFO: task btrfs-transacti:3701 blocked for more than 120
seconds.
[ 1440.330014] Not tainted 4.4.82+525-ph #1
[ 1440.330015] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables
We have a WARN_ON(!var) inside an if branch which is executed (among others)
only when var is true.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 21c78c48e15b..8552d550a048 100644
Chris Murphy posted on Wed, 16 Aug 2017 17:32:36 -0600 as excerpted:
> On Tue, Aug 15, 2017 at 7:12 PM, Paulo Dias
> wrote:
> Device Model: Samsung SSD 850 EVO M.2 500GB Serial Number:
> S33DNX0H812686V LU WWN Device Id: 5 002538 d4130d027 Firmware Version:
> EMT21B6Q
> Unfortun
On 2017-08-17 02:25, GWB wrote:
<<
Or else it could be an argument that they
expect Btrfs to do their job while they watch cat videos from the
intertubes. :-)
My favourite quote from the list this week, and, well, obviously, that
is the main selling point of file systems like btrfs, zfs, and
On Thu, Aug 17, 2017 at 10:52:28AM +0300, Nikolay Borisov wrote:
> We have a WARN_ON(!var) inside an if branch which is executed (among others)
> only when var is true.
>
> Signed-off-by: Nikolay Borisov
> ---
> fs/btrfs/extent-tree.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/fs/b
On Wed, Aug 16, 2017 at 06:41:44PM +0300, Nikolay Borisov wrote:
> This variable was added in 1abe9b8a138c ("Btrfs: add initial tracepointi
> support for btrfs"), yet it never really got used, only assigned to. So let's
> remove it.
>
> Signed-off-by: Nikolay Borisov
Reviewed-by: David Sterba
-
On Wed, Aug 16, 2017 at 06:15:23PM +0300, Nikolay Borisov wrote:
> The internal free space tree management routines are always exposed for
> testing
> purposes. Make them dependent on SANITY_TESTS being on so that they are
> exposed
> only when they really have to.
>
> Signed-off-by: Nikolay Bor
On Tue, Aug 15, 2017 at 08:51:02AM +0100, Colin King wrote:
> From: Colin Ian King
>
> The error return variable ret is initialized to zero and then is
> checked to see if it is non-zero in the if-block that follows it.
> It is therefore impossible for ret to be non-zero after the if-block
> henc
On Thu, Aug 17, 2017 at 04:33:41AM +0800, Anand Jain wrote:
>
>
> On 08/16/2017 09:59 PM, David Sterba wrote:
> > On Sun, Aug 13, 2017 at 12:02:42PM +0800, Anand Jain wrote:
> >> There isn't a huge list to manage the types, which can be managed
> >> with defines. It helps to easily print the type
We have a WARN_ON(!var) inside an if branch which is executed (among others)
only when var is true.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 21c78c48e15b..
On 8/2/17 3:54 PM, je...@suse.com wrote:
> From: Jeff Mahoney
>
> btrfs_find_root and btrfs_del_root always use the tree_root. Let's pass
> fs_info instead.
This one is broken. btrfs_read_fs_root is called during log tree
recovery with the log_root_tree. I'll send an updated patch.
-Jeff
>
btrfs_del_roots always uses the tree_root. Let's pass fs_info instead.
Signed-off-by: Jeff Mahoney
---
fs/btrfs/ctree.h | 4 ++--
fs/btrfs/extent-tree.c | 2 +-
fs/btrfs/free-space-tree.c | 2 +-
fs/btrfs/qgroup.c | 3 +--
fs/btrfs/root-tree.c | 7 ---
5 files c
Hi,
On 08/15/2017 12:57 AM, Piotr Szymaniak wrote:
> and... some issues:
> ~ # btrfs fi du -s /mnt/red/\@backup/
> Total Exclusive Set shared Filename
> ERROR: cannot check space of '/mnt/red/@backup/': Inappropriate ioctl for
> device
could you share the output of
strace btrfs fi du
Readding Btrfslist, and adding Qu:
On Thu, Aug 17, 2017 at 12:48 AM, Zirconium Hacker wrote:
> Oh, sorry, I guess the output of the command I ran wasn't clear -- it
> was collecting the output of running the debug command on all 1,084
> and showing that it was the same. Here's specifically what
From: Josef Bacik
Right now we do a lot of weird hoops around outstanding_extents in order
to keep the extent count consistent. This is because we logically
transfer the outstanding_extent count from the initial reservation
through the set_delalloc_bits. This makes it pretty difficult to get a
# btrfs sub create test1
Create subvolume './test1'
# btrfs sub create test1/test2
Create subvolume 'test1/test2'
# btrfs sub snap test1 test1.snap
Create a snapshot of 'test1' in './test1.snap'
# btrfs fi du -s test1
Total Exclusive Set shared Filename
0.00B 0.00B 0.00B
On Thu, Aug 17, 2017 at 5:47 AM, Austin S. Hemmelgarn
wrote:
> Also, I don't think I've ever seen any patches posted from a Red Hat address
> on the ML, so I don't think they were really all that involved in
> development to begin with.
Unfortunately the email domain doesn't tell the whole story
On Thu, Aug 17, 2017 at 2:04 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> The point being, as I said, unless Samsung's changed policy recently,
> there's no point in filing Linux related bug reports with them. All
> you're likely to get is them putting their fingers in their ears while
> singing lo
HI/2 all, once again thanky you for taking time to look at this.
So i disabled discard in the mount options yesterday, recreated the
Fedora.qcow file outside of the /home subvolume, and copied it back to
/home.
It "appeared" ok for a while, but today i run scrub on /home again,
and sure enough:
Yep, and thank you to Suse, Fujitsu, and all the contributors.
I suppose we can all be charitable when reading this from the Red Hat
Whitepaper at:
https://www.redhat.com/whitepapers/rha/gfs/GFS_INS0032US.pdf:
<<
Red Hat GFS is the world’s leading cluster file system for Linux.
>>
If that is G
Hi,
On one of my machines I run a BTRFS filesystem with the following
configuration
Kernel: 4.11.0-1-amd64 #1 SMP Debian 4.11.6-1 (2017-06-19) x86_64 GNU/Linux
Disks: 8
Metadata: Raid 10
Data: Raid1
One of the disks is going bad , and while the system still runs fine I
ran some md5sum's on a
On Wed, Aug 16, 2017 at 06:25:54PM -0400, Zirconium Hacker wrote:
> Hi,
> This is my first time using a mailing list, and I hope I'm doing this right.
>
> $ uname -a
> Linux thinkpad 4.12.6-1-ARCH #1 SMP PREEMPT Sat Aug 12 09:16:22 CEST
> 2017 x86_64 GNU/Linux
> $ btrfs --version
> btrfs-progs v4.
First post
235 POR_Recovery_Count 0x0012 099 099 000Old_age
Always - 54
Recent post
235 POR_Recovery_Count -O--C- 099 099 000-55
So you've had one more of these POR events.
http://www.samsung.com/semiconductor/minisite/ssd/downloads/document/Samsun
Hi,
On 08/17/2017 08:43 PM, Chris Murphy wrote:
> # btrfs sub create test1
> Create subvolume './test1'
> # btrfs sub create test1/test2
> Create subvolume 'test1/test2'
> # btrfs sub snap test1 test1.snap
> Create a snapshot of 'test1' in './test1.snap'
> # btrfs fi du -s test1
> Total Exc
From: Josef Bacik
The way we handle delalloc metadata reservations has gotten
progressively more complicated over the years. There is so much cruft
and weirdness around keeping the reserved count and outstanding counters
consistent and handling the error cases that it's impossible to
understand.
2017-07-29 16:36 GMT+03:00 Timofey Titovets :
> Based on kdave for-next
> As heuristic skeleton already merged
> Populate heuristic with basic code.
>
> First patch: add simple sampling code
> It's get 16 byte samples with 256 bytes shifts
> over input data. Collect info about how many
> different
On Thu, Aug 17, 2017 at 10:41:59PM +0200, waxhead wrote:
> Hi,
>
> On one of my machines I run a BTRFS filesystem with the following
> configuration
>
> Kernel: 4.11.0-1-amd64 #1 SMP Debian 4.11.6-1 (2017-06-19) x86_64 GNU/Linux
> Disks: 8
> Metadata: Raid 10
> Data: Raid1
>
> One of the disks i
On 2017年08月18日 00:53, Chris Murphy wrote:
Readding Btrfslist, and adding Qu:
On Thu, Aug 17, 2017 at 12:48 AM, Zirconium Hacker wrote:
Oh, sorry, I guess the output of the command I ran wasn't clear -- it
was collecting the output of running the debug command on all 1,084
and showing that i
On Tue, Aug 15, 2017 at 10:12:28PM -0300, Paulo Dias wrote:
> Hello/2 all
>
> I'm using libvirt with a qcow2 image and everytime i run btrfs scrub
> -H /home (subvolume where the image is), i get:
>
> ago 15 21:58:08 kerberos kernel: BTRFS error (device sda3): bdev
> /dev/sda3 errs: wr 0, rd 0, f
I hope "Reply All" is the right option here. Again, first time
interacting with a mailing list. Google said that was what to do.
I have found no I/O errors in dmesg -- at least, none mentioning
'I/O', 'IO', or anything triggered by mount besides BTRFS's
complaints.
$ sudo btrfs rescue chunk -v
On 2017年08月18日 11:13, Zirconium Hacker wrote:
I hope "Reply All" is the right option here. Again, first time
interacting with a mailing list. Google said that was what to do.
You're doing quite well, and yes, Reply All is the right option.
I have found no I/O errors in dmesg -- at least,
On Thu, Aug 17, 2017 at 4:42 PM, Qu Wenruo wrote:
> BTW are you using discard mount option? Sometimes it can cause problem.
OP did not say if it was using discard mount option; but did say some
time before this (I'm not sure how recent) he had used fstrim. The
firmware for this SSD model is curr
On 17.08.2017 23:59, Goffredo Baroncelli wrote:
> Hi,
>
> On 08/17/2017 08:43 PM, Chris Murphy wrote:
>> # btrfs sub create test1
>> Create subvolume './test1'
>> # btrfs sub create test1/test2
>> Create subvolume 'test1/test2'
>> # btrfs sub snap test1 test1.snap
>> Create a snapshot of 'test1'
33 matches
Mail list logo
