On 09/21/2015 10:10 AM, Qu Wenruo wrote:
Just the same for mount time check, use new btrfs_check_degraded() to do
per chunk check.
Signed-off-by: Qu Wenruo
---
fs/btrfs/super.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super
btrfs_error() and btrfs_std_error() does the same thing
and calls _btrfs_std_error(), so consolidate them together.
And the main motivation is that btrfs_error() is closely
named with btrfs_err(), one handles error action the other
is to log the error, so don't closely name them.
Signed-off-by: An
Mark Fasheh wrote on 2015/09/22 13:15 -0700:
Hi,
The following 4 patches fix a regression introduced in Linux
4.2 where btrfs_drop_snapshot() wasn't updating qgroups, resulting in
them going bad.
The original e-mail pointing this out is below:
http://www.spinics.net/lists/linux-btrfs/msg4609
Ancient qgroup code call memcpy() on a extent buffer and use it for leaf
iteration.
As extent buffer contains lock, pointers to pages, it's never sane to do
such copy.
The following bug may be caused by this insane operation:
[92098.841309] general protection fault: [#1] SMP
[92098.841338] M
Normal btrfs_item_key_to_cpu() will need extent buffer to do it, and
there is not stack version to handle in memory leaf.
Add btrfs_stack_item_key_to_cpu() function for such operation, which
will provide the basis for later qgroup fix.
Signed-off-by: Qu Wenruo
---
fs/btrfs/ctree.h | 20
Stephane Lesimple reported an qgroup rescan bug:
[92098.841309] general protection fault: [#1] SMP
[92098.841338] Modules linked in: ...
[92098.841814] CPU: 1 PID: 24655 Comm: kworker/u4:12 Not tainted
4.3.0-rc1 #1
[92098.841868] Workqueue: btrfs-qgroup-rescan btrfs_qgroup_rescan_helper
[btrf
On Thu, Sep 24, 2015 at 11:07:32PM +0200, Sjoerd wrote:
> Maybe a silly question for most of you, but the wiki states to always try to
> use the latest kernel with btrfs. Which one would be best:
> - 4.2.1 (currently latest stable and matches the btrfs-progs versioning) or
> - the 4.3.x (mainline
Maybe a silly question for most of you, but the wiki states to always try to
use the latest kernel with btrfs. Which one would be best:
- 4.2.1 (currently latest stable and matches the btrfs-progs versioning) or
- the 4.3.x (mainline)?
Stable sounds more stable to me(hence the name ;) ), but the
We have a mechanism to make sure we don't lose updates for ordered extents that
were logged in the transaction that is currently running. We add the ordered
extent to a transaction list and then the transaction waits on all the ordered
extents in that list. However are substantially large file sy
On 2015-09-24 14:48, Matwey V. Kornilov wrote:
2015-09-24 21:35 GMT+03:00 Austin S Hemmelgarn :
On 2015-09-24 14:06, Matwey V. Kornilov wrote:
Hello,
I would like to read the list of the checksums for the specific file
stored onto btrfs filesystem. I think I could use the checksums in the
ma
check-integrity is using -1 instead of the -ENOMEM defined macro to
specify that a buffer allocation failed. Since the error number is
propagated, the caller will get a -EPERM which is the wrong error
condition.
Also, the smatch tool complains with the following warnings:
btrfsic_process_superbloc
Hi,
These two patches fix instances where -1 is used to specify a buffer
allocation fail, instead of using -ENOMEM.
Patch 1/2 is already reviewed by David Sterba.
Luis de Bethencourt (2):
btrfs: check-integrity: Fix returned errno codes
btrfs: reada: Fix returned errno code
fs/btrfs/check-
reada is using -1 instead of the -ENOMEM defined macro to specify that
a buffer allocation failed. Since the error number is propagated, the
caller will get a -EPERM which is the wrong error condition.
Also, updating the caller to return the exact value from
reada_add_block.
Smatch tool warning:
2015-09-24 21:35 GMT+03:00 Austin S Hemmelgarn :
> On 2015-09-24 14:06, Matwey V. Kornilov wrote:
>>
>>
>> Hello,
>>
>> I would like to read the list of the checksums for the specific file
>> stored onto btrfs filesystem. I think I could use the checksums in the
>> manner like rsync does, but safe
On 2015-09-24 14:06, Matwey V. Kornilov wrote:
Hello,
I would like to read the list of the checksums for the specific file
stored onto btrfs filesystem. I think I could use the checksums in the
manner like rsync does, but safe both CPU (because csums are already
calculated for the file) and I/O
Hello,
I would like to read the list of the checksums for the specific file
stored onto btrfs filesystem. I think I could use the checksums in the
manner like rsync does, but safe both CPU (because csums are already
calculated for the file) and I/O (because I don't need to reread all the
file fro
On Thu, Sep 24, 2015 at 8:34 AM, Jogi Hofmüller wrote:
> All this runs on a virtual machine that uses kernel 4.1.3 (Debian build)
> and btrfs-progs v4.0.
Unrelated to the problem but I'd upgrade progs, in case it's ever
needed. 4.1 and 4.2 have tons of bug fixes over 4.0 already.
>
> So finall
On 18 September 2015 at 14:10, Austin S Hemmelgarn wrote:
> On 2015-09-17 10:52, Aneurin Price wrote:
>>
>> On 16 September 2015 at 20:21, Austin S Hemmelgarn
>> wrote:
>>>
>>> ZFS has been around for much longer, it's been mature and feature
>>> complete for more than a decade, and has had a lon
I want to set some per transaction flags, so instead of adding yet another int
lets just convert the current two int indicators to flags and add a flags field
for future use. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/extent-tree.c | 5 +++--
fs/btrfs/transaction.c | 18 --
Hi all,
We experience strange Input/output errors on our mail server (dovecot
pop/imap) that is using btrfs for its mailspool.
The server uses software RAID10. The RAID is split into LVMs. The
mailspool logical volume uses btrfs. For several days now we see
Input/output errors on different fil
2015-09-01 3:08 GMT+03:00 Dāvis Mosāns :
>
> Here's a btrfs-image from that filesystems /dev/sdb
> https://drive.google.com/file/d/0B82_Tz1_6URAQmV5LTZHUmR4YXM/view?usp=sharing
> sha256sum
> 88fb561b4a581319ae18c1f27b6ac108e9c08ff80954e192cb3201cc5d4c19ff raid1_sdb.img
> size 142M
>
> only differen
21 matches
Mail list logo
