Nils Holland wrote:
> On Sat, Dec 17, 2016 at 11:44:45PM +0900, Tetsuo Handa wrote:
> > On 2016/12/17 21:59, Nils Holland wrote:
> > > On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote:
> > >> mount -t tracefs none /debug/trace
> > >> echo 1 > /debug/trace/events/vmscan/enable
> > >> cat
Hi,
The system supposes to have special memory reservation for coredump and other
debug info when encountering panic,
the size seems configurable.
Thanks,
Xin
Sent: Saturday, December 17, 2016 at 6:44 AM
From: "Tetsuo Handa"
To: "Nils Holland" , "Michal Hocko"
Cc: linux-ker...@vger.kernel.o
On 25. nov. 2016 21:19, Kai Stian Olstad wrote:
I have problem mounting my 3 disk raid1.
This happened after upgrading from Kubuntu 14.04 to 16.04.
I finally found the problem.
Since I needed to reboot after the upgrade I decided to add some disks,
and in order to do that I needed to move aroun
On Sat, Dec 17, 2016 at 11:44:45PM +0900, Tetsuo Handa wrote:
> On 2016/12/17 21:59, Nils Holland wrote:
> > On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote:
> >> mount -t tracefs none /debug/trace
> >> echo 1 > /debug/trace/events/vmscan/enable
> >> cat /debug/trace/trace_pipe > trace
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
Sent: Saturday, December 17, 2016 at 2:06 AM
From: "Jari Seppälä"
To: linux-btrfs@vger.kernel.org
Subject: Help
On Sat, Dec 17, 2016 at 11:44:45PM +0900, Tetsuo Handa wrote:
> On 2016/12/17 21:59, Nils Holland wrote:
> > On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote:
> >> mount -t tracefs none /debug/trace
> >> echo 1 > /debug/trace/events/vmscan/enable
> >> cat /debug/trace/trace_pipe > trace
On 2016/12/17 21:59, Nils Holland wrote:
> On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote:
>> mount -t tracefs none /debug/trace
>> echo 1 > /debug/trace/events/vmscan/enable
>> cat /debug/trace/trace_pipe > trace.log
>>
>> should help
>> [...]
>
> No problem! I enabled writing the t
On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote:
> On Fri 16-12-16 19:47:00, Nils Holland wrote:
> >
> > Dec 16 18:56:24 boerne.fritz.box kernel: Purging GPU memory, 37 pages
> > freed, 10219 pages still pinned.
> > Dec 16 18:56:29 boerne.fritz.box kernel: kthreadd invoked oom-killer
Michal Hocko wrote:
> On Fri 16-12-16 12:31:51, Johannes Weiner wrote:
>>> @@ -3737,6 +3752,16 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int
>>> order,
>>> */
>>> WARN_ON_ONCE(order > PAGE_ALLOC_COSTLY_ORDER);
>>>
>>> + /*
>>> +* Help non-f
Syslog tells:
[ 135.446222] BTRFS error (device sdb1): system chunk array too small 0 < 97
[ 135.446260] BTRFS error (device sdb1): superblock contains fatal errors
[ 135.462544] BTRFS error (device sdb1): open_ctree failed
What have been done:
* All "btrfs rescue" options
Info on system
* fs
On Saturday 17 December 2016 00:18:13 Marc Joliet wrote:
> Is this something that btrfs-check can safely repair, or that is perhaps
> even harmless?
Never mind, I just found that this has been repairable since btrfs-progs 3.19.
Greetings
--
Marc Joliet
--
"People who think they know everything
OK, btrfs-check finished about an hour after I sent this, here's the complete
output:
# btrfs check /dev/sdd2
Checking filesystem on /dev/sdd2
UUID: f97b3cda-15e8-418b-bb9b-235391ef2a38
checking extents
checking free space cache
checking fs roots
root 30634 inode 95066 errors 100, file ext
12 matches
Mail list logo
