Xin Zhou kirjoitti 19.12.2016 kello 20.44:
>
> Hi Jari,
>
> The message shows:
>> [ 135.446260] BTRFS error (device sdb1): superblock contains fatal errors
>
> So according this info, before trying to run repair / rescue procedure, would
> you like to show the 0,1,2 superblock status?
>
btrfs
Further info:
I tested several versions of old kernel starts from v4.7, and they all
failed on two of my physical machines.
But strangely, they all passed in KVM guests using virtio.
Not sure if it's related to the device size (over 50G for each device in
physical machines, while less than 1
On Monday, December 19, 2016 02:56:41 PM Qu Wenruo wrote:
> Since we have the whole facilities needed to rollback, switch to the new
> rollback.
>
> The new rollback function can handle the following things that old
> rollback either can't handle or just refuse to rollback:
>
> 1) New converted b
On Mon, Dec 19, 2016 at 02:45:34PM +0100, Michal Hocko wrote:
> Unfortunatelly shrink_active_list doesn't have any tracepoint so we do
> not know whether we managed to rotate those pages. If they are referenced
> quickly enough we might just keep refaulting them... Could you try to apply
> the fol
Btrfs upstream doesn't accept stream-version, so the test is never ran
on upstream kernel nor btrfs-progs.
Just remove it.
Signed-off-by: Qu Wenruo
---
common/btrfs| 14 --
tests/btrfs/047 | 120
tests/btrfs/047.out | 35 ---
On Tue, Dec 20, 2016 at 08:24:13AM +1100, Dave Chinner wrote:
> On Thu, Dec 15, 2016 at 03:07:08PM +0100, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Now that the page allocator offers __GFP_NOLOCKDEP let's introduce
> > KM_NOLOCKDEP alias for the xfs allocation APIs. While we are at it
>
On Thu, Dec 15, 2016 at 03:07:08PM +0100, Michal Hocko wrote:
> From: Michal Hocko
>
> Now that the page allocator offers __GFP_NOLOCKDEP let's introduce
> KM_NOLOCKDEP alias for the xfs allocation APIs. While we are at it
> also change KM_NOFS users introduced by b17cb364dbbb ("xfs: fix missing
On 12/19/16 3:09 PM, Jeff Mahoney wrote:
> commit e5d6b12fe14e89ea1c494585c47b1dfb31d71183
> Author: Chris Mason
> Date: Fri Dec 9 05:56:33 2016 -0800
>
> Btrfs: don't WARN() in btrfs_transaction_abort() for IO errors
>
> btrfs_transaction_abort() has a WARN() to help us nail down what
commit e5d6b12fe14e89ea1c494585c47b1dfb31d71183
Author: Chris Mason
Date: Fri Dec 9 05:56:33 2016 -0800
Btrfs: don't WARN() in btrfs_transaction_abort() for IO errors
btrfs_transaction_abort() has a WARN() to help us nail down whatever
problem lead to the abort. But most of the ti
a concrete example
SNAPSHOT
/dev/nvme0n1p2 on /tmp/tmp.X3vU6dLLVI type btrfs
(rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
btrfsManage SNAPSHOT /
(2016-12-19 19:44:00) Start btrfsManage
. . . Start managing SNAPSHOT ' / ' filesystem ' root ' snapshot
In ' btrfssnapshot ' latest source sn
Rereading this...
On 12/19/2016 12:53 AM, Hans van Kranenburg wrote:
> [...]
>
> Qu Wenruo pointed out that the greyscale value used for dev_extent (the
> usage for the block group is used here) does not necessarily have to be
> correct: "And for 50%/50% assumption for RAID0, it's not true and we
Hi Jari,
The message shows:
> [ 135.446260] BTRFS error (device sdb1): superblock contains fatal errors
So according this info, before trying to run repair / rescue procedure, would
you like to show the 0,1,2 superblock status?
Regards,
Xin
Sent: Monday, December 19, 2016 at 2:32 AM
From:
On Tue, Dec 13, 2016 at 02:39:34PM -0500, Jeff Mahoney wrote:
> btrfs_add_delayed_data_ref is always called with a NULL extent_op,
> so let's drop the argument.
>
> Signed-off-by: Jeff Mahoney
Reviewed-by: David Sterba
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
Hi,
We are interested in testing out and possibly contribute to the btrfs
dedup effort. I¹ve been looking around the github at:
git://repo.or.cz/btrfs-progs-unstable/devel.git
And I couldn¹t locate any of the patch set some of you mentioned in the
posts such as:
http://www.spinics.net/lists/linu
On Mon, Dec 19, 2016 at 9:53 AM, Geliang Tang
wrote:
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang
Reviewed-by: Josef Bacik
Thanks,
Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang
---
fs/btrfs/ctree.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index a426dc8..146b2dc 100644
--- a/fs/btrfs/ct
On Sat 17-12-16 22:06:47, Nils Holland wrote:
[...]
> Unfortunately, the reclaim trace messages stopped a while after the first
> OOM messages show up - most likely my "cat" had been killed at that
> point or became unresponsive. :-/
The later is more probable because I do not see the OOM killer t
(Resend)
Hi.
It is a bit complex.
Primary system
subvolume on SSD devices on PCIe slot
/root/ (fedora 23, 50GB usati)
/btrfssnapshot/
/btrfssnapshot/root/ (for /root/ snapshot)
/btrfssnapshot/root/root.1
/btrfssnapshot/root/root.2
/btrfssnapshot/root/root.XYZ
subvolume on device HDD "1" s
>
>
> At 11/21/2016 08:09 PM, b...@adria.it wrote:
> > Hi.
> >
> > My system: Fedora 23, kernel-4.7.10-100.fc23.x86_64
> btrfs-progs-4.4.1-1.fc23.x86_64
> >
> > Testing the remote differential receive (via ssh and in local network) of
> 24
> > sequential snapshots, and simultaneously deleting the
On Tuesday 06 December 2016 00:22:39 Marc Joliet wrote:
> On Monday 05 December 2016 11:16:35 Marc Joliet wrote:
> [...]
>
> > https://dl.dropboxusercontent.com/u/5328255/arthur_root_4.7.3_sanitized.im
> > ag e.xz
> > https://dl.dropboxusercontent.com/u/5328255/arthur_root_4.8.5_sanitized.im
> > a
On Saturday 17 December 2016 00:18:13 Marc Joliet wrote:
> The initial results with btrfs-check's low-memory mode found
> reference count mismatches, but that seems to have been a false positive,
> since btrfs-check's normal mode does not find them.
FWIW, just in case this wasn't known yet (I kn
On 12/13/16 01:19, David Sterba wrote:
On Tue, Dec 06, 2016 at 12:39:37PM +0800, Anand Jain wrote:
The command,
btrfs fi defrag -v /btrfs
does nothing, it won't defrag the files under /btrfs as user
may expect. The command with recursive option
btrfs fi defrag -vr /btrfs
would defrag
(sorry for the delay due to my vacation).
On 12/12/16 22:12, David Sterba wrote:
On Tue, Dec 06, 2016 at 12:43:09PM +0800, Anand Jain wrote:
As of now writes smaller than 64k for non compressed extents and 16k
for compressed extents inside eof are considered as candidate
for auto defrag, put t
As of now writes smaller than 64k for non compressed extents and 16k
for compressed extents inside eof are considered as candidate
for auto defrag, put them together at a place.
Signed-off-by: Anand Jain
---
v2: pass value of small write, and current num_bytes.
fix sign-off.
fs/btrfs/inode.
Xin Zhou kirjoitti 17.12.2016 kello 22.27:
>
> Hi Jari,
>
> Similar with other file system, btrfs has copies of super blocks.
> Try to run "man btrfs check", "man btrfs rescue" and related commands for
> more details.
> Regards,
> Xin
Hi Xin,
I did follow all recovery procedures from man and
On Thu 15-12-16 15:07:15, Michal Hocko wrote:
> From: Michal Hocko
>
> This reverts commit 216553c4b7f3e3e2beb4981cddca9b2027523928. Now that
> the transaction context uses memalloc_nofs_save and all allocations
> within the this context inherit GFP_NOFS automatically, there is no
> reason to mar
On Thu 15-12-16 15:07:13, Michal Hocko wrote:
> From: Michal Hocko
>
> kjournald2 is central to the transaction commit processing. As such any
> potential allocation from this kernel thread has to be GFP_NOFS. Make
> sure to mark the whole kernel thread GFP_NOFS by the memalloc_nofs_save.
>
> Su
On Thu 15-12-16 15:07:12, Michal Hocko wrote:
> From: Michal Hocko
>
> now that we have memalloc_nofs_{save,restore} api we can mark the whole
> transaction context as implicitly GFP_NOFS. All allocations will
> automatically inherit GFP_NOFS this way. This means that we do not have
> to mark any
On Thu 15-12-16 15:07:14, Michal Hocko wrote:
> From: Michal Hocko
>
> This reverts commit c45653c341f5c8a0ce19c8f0ad4678640849cb86 because
> sb_getblk_gfp is not really needed as
> sb_getblk
> __getblk_gfp
> __getblk_slow
> grow_buffers
> grow_dev_page
> gfp_mask = ma
On Fri 16-12-16 17:27:28, Mike Galbraith wrote:
> On Fri, 2016-12-16 at 16:35 +0100, Michal Hocko wrote:
> > On Fri 16-12-16 16:05:58, Mike Galbraith wrote:
> > > On Thu, 2016-12-15 at 15:07 +0100, Michal Hocko wrote:
> > > > Hi,
> > > > I have posted the previous version here [1]. Since then I hav
30 matches
Mail list logo
