In btrfs-dump-tree, we output any existing log tree, however we don't
output the log root tree, which records all root items for log trees.
This makes it confusing for any one who want to know where the log tree
comes from.
Signed-off-by: Qu Wenruo
---
cmds-inspect-dump-tree.c | 20
Peter Grandi posted on Fri, 03 Mar 2017 00:47:46 + as excerpted:
>> [ ... ] Meanwhile, the problem as I understand it is that at the first
>> raid1 degraded writable mount, no single-mode chunks exist, but without
>> the second device, they are created. [ ... ]
>
> That does not make any sen
After 76b42abbf748 ("Btrfs: fix data loss after truncate when using the
no-holes feature"),
For either NO_HOLES or inline extents, we've set last_size to newsize to
avoid data loss after remount or inode got evicted and read again, thus,
we don't need this check anymore.
Signed-off-by: Liu Bo
--
On Thu, Mar 02, 2017 at 02:18:21PM -0800, Liu Bo wrote:
> On Tue, Jul 14, 2015 at 04:34:48PM +0100, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > Using the clone ioctl (or extent_same ioctl, which calls the same extent
> > cloning function as well) we end up allowing copy an inline e
On Thu, Mar 02, 2017 at 07:58:01AM -0800, Liu Bo wrote:
> On Wed, Mar 01, 2017 at 03:03:19PM -0500, Dave Jones wrote:
> > On Tue, Feb 28, 2017 at 05:12:01PM -0800, Liu Bo wrote:
> > > On Mon, Feb 27, 2017 at 11:23:42AM -0500, Dave Jones wrote:
> > > > On Mon, Feb 27, 2017 at 07:53:48AM -0800, Liu
On Thu, Mar 2, 2017 at 6:18 PM, Qu Wenruo wrote:
>
>
> At 03/03/2017 09:15 AM, Chris Murphy wrote:
>>
>> [1805985.267438] BTRFS info (device dm-6): allowing degraded mounts
>> [1805985.267566] BTRFS info (device dm-6): disk space caching is enabled
>> [1805985.267676] BTRFS info (device dm-6): has
At 03/02/2017 05:43 PM, Marc Joliet wrote:
On Thursday 02 March 2017 08:43:53 Qu Wenruo wrote:
At 02/02/2017 08:01 PM, Marc Joliet wrote:
On Sunday 28 August 2016 15:29:08 Kai Krakow wrote:
Hello list!
Hi list
[kernel message snipped]
Btrfs --repair refused to repair the filesystem tel
At 03/03/2017 09:15 AM, Chris Murphy wrote:
[1805985.267438] BTRFS info (device dm-6): allowing degraded mounts
[1805985.267566] BTRFS info (device dm-6): disk space caching is enabled
[1805985.267676] BTRFS info (device dm-6): has skinny extents
[1805987.187857] BTRFS warning (device dm-6): mi
At 03/02/2017 05:44 PM, Marc Joliet wrote:
On Wednesday 01 March 2017 19:14:07 Marc Joliet wrote:
In any
case, I started btrfs-check on the device itself.
OK, it's still running, but the output so far is:
# btrfs check --mode=lowmem --progress /dev/sdb2
Checking filesystem on /dev/sdb2
UUID
[1805985.267438] BTRFS info (device dm-6): allowing degraded mounts
[1805985.267566] BTRFS info (device dm-6): disk space caching is enabled
[1805985.267676] BTRFS info (device dm-6): has skinny extents
[1805987.187857] BTRFS warning (device dm-6): missing devices (1)
exceeds the limit (0), writeab
> [ ... ] Meanwhile, the problem as I understand it is that at
> the first raid1 degraded writable mount, no single-mode chunks
> exist, but without the second device, they are created. [
> ... ]
That does not make any sense, unless there is a fundamental
mistake in the design of the 'raid1' prof
At 03/03/2017 01:28 AM, Filipe Manana wrote:
On Tue, Feb 28, 2017 at 2:28 AM, Qu Wenruo wrote:
[BUG]
Reports about btrfs hang running btrfs/124 with default mount option and
btrfs/125 with nospace_cache or space_cache=v2 mount options, with
following backtrace.
Call Trace:
__schedule+0x2d4/
On Thu, Mar 02, 2017 at 04:01:17PM +0300, Dmitry V. Levin wrote:
> On Thu, Mar 02, 2017 at 12:42:12PM +0100, David Sterba wrote:
> > On Wed, Mar 01, 2017 at 03:54:35PM +0100, David Sterba wrote:
> > > On Wed, Mar 01, 2017 at 02:12:50AM +0300, Dmitry V. Levin wrote:
> > > > btrfs_err_str function is
On Tue, Feb 28, 2017 at 2:28 AM, Qu Wenruo wrote:
> [BUG]
> Reports about btrfs hang running btrfs/124 with default mount option and
> btrfs/125 with nospace_cache or space_cache=v2 mount options, with
> following backtrace.
>
> Call Trace:
> __schedule+0x2d4/0xae0
> schedule+0x3d/0x90
> btrfs_
On 2017-03-02 12:26, Andrei Borzenkov wrote:
02.03.2017 16:41, Duncan пишет:
Chris Murphy posted on Wed, 01 Mar 2017 17:30:37 -0700 as excerpted:
[1717713.408675] BTRFS warning (device dm-8): missing devices (1)
exceeds the limit (0), writeable mount is not allowed
[1717713.446453] BTRFS error
On Tue, Jul 14, 2015 at 04:34:48PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Using the clone ioctl (or extent_same ioctl, which calls the same extent
> cloning function as well) we end up allowing copy an inline extent from
> the source file into a non-zero offset of the destina
Hi Linus,
My for-linus-4.11 branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus-4.11
Has Btrfs round two. These are mostly a continuation of Dave Sterba's
collection
of cleanups, but Filipe also has some bug fixes and performance improvements.
Nikolay Boriso
Add file entries for btrfs header files.
Signed-off-by: Dmitry V. Levin
Acked-by: David Sterba
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0001835..04a758f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2904,6 +2904,8 @@ T:git
g
02.03.2017 16:41, Duncan пишет:
> Chris Murphy posted on Wed, 01 Mar 2017 17:30:37 -0700 as excerpted:
>
>> [1717713.408675] BTRFS warning (device dm-8): missing devices (1)
>> exceeds the limit (0), writeable mount is not allowed
>> [1717713.446453] BTRFS error (device dm-8): open_ctree failed
>>
On Wed, Mar 01, 2017 at 03:03:19PM -0500, Dave Jones wrote:
> On Tue, Feb 28, 2017 at 05:12:01PM -0800, Liu Bo wrote:
> > On Mon, Feb 27, 2017 at 11:23:42AM -0500, Dave Jones wrote:
> > > On Mon, Feb 27, 2017 at 07:53:48AM -0800, Liu Bo wrote:
> > > > On Sun, Feb 26, 2017 at 07:18:42PM -0500, D
On Thu 02-03-17 06:12:45, Matthew Wilcox wrote:
> On Thu, Mar 02, 2017 at 11:38:45AM +0100, Jan Kara wrote:
> > On Wed 01-03-17 07:38:57, Christoph Hellwig wrote:
> > > On Tue, Feb 28, 2017 at 07:46:06PM -0800, Matthew Wilcox wrote:
> > > > But what's going to kick these pages out of cache? Should
Chris Murphy posted on Wed, 01 Mar 2017 17:30:37 -0700 as excerpted:
> [1717713.408675] BTRFS warning (device dm-8): missing devices (1)
> exceeds the limit (0), writeable mount is not allowed
> [1717713.446453] BTRFS error (device dm-8): open_ctree failed
>
> [chris@f25s ~]$ uname
> -r 4.9.8-200
Hi,
a pre-release has been tagged. There are patches that have queued so far, but
I haven't gone through everything that's in the mailinglist. The 4.10 release
ETA is next week so I'll try to process the backlog and merge what would seem
applicable.
Changes:
* send: dump output fixes: missing n
On Thu, Mar 02, 2017 at 11:38:45AM +0100, Jan Kara wrote:
> On Wed 01-03-17 07:38:57, Christoph Hellwig wrote:
> > On Tue, Feb 28, 2017 at 07:46:06PM -0800, Matthew Wilcox wrote:
> > > But what's going to kick these pages out of cache? Shouldn't we rather
> > > find the pages, kick them out if cle
On Wed, Mar 01, 2017 at 03:54:35PM +0100, David Sterba wrote:
> On Wed, Mar 01, 2017 at 02:12:50AM +0300, Dmitry V. Levin wrote:
> > btrfs_err_str function is not called from anywhere and is replicated
> > in the userspace headers for btrfs-progs.
> >
> > It's removal also fixes the following linu
On Thu, Mar 02, 2017 at 12:42:12PM +0100, David Sterba wrote:
> On Wed, Mar 01, 2017 at 03:54:35PM +0100, David Sterba wrote:
> > On Wed, Mar 01, 2017 at 02:12:50AM +0300, Dmitry V. Levin wrote:
> > > btrfs_err_str function is not called from anywhere and is replicated
> > > in the userspace header
On Wed, Mar 01, 2017 at 05:30:37PM -0700, Chris Murphy wrote:
> [1717713.408675] BTRFS warning (device dm-8): missing devices (1)
> exceeds the limit (0), writeable mount is not allowed
> [1717713.446453] BTRFS error (device dm-8): open_ctree failed
>
> [chris@f25s ~]$ uname -r
> 4.9.8-200.fc25.x8
On Wed 01-03-17 07:38:57, Christoph Hellwig wrote:
> On Tue, Feb 28, 2017 at 07:46:06PM -0800, Matthew Wilcox wrote:
> > Ugh, this is pretty inefficient. If that's all you want to know, then
> > using the radix tree directly will be far more efficient than spinning
> > up all the pagevec machinery
On Wednesday 01 March 2017 19:14:07 Marc Joliet wrote:
> In any
> case, I started btrfs-check on the device itself.
OK, it's still running, but the output so far is:
# btrfs check --mode=lowmem --progress /dev/sdb2
Checking filesystem on /dev/sdb2
UUID: f97b3cda-15e8-418b-bb9b-235391ef2a38
ERROR
On Thursday 02 March 2017 08:43:53 Qu Wenruo wrote:
> At 02/02/2017 08:01 PM, Marc Joliet wrote:
> > On Sunday 28 August 2016 15:29:08 Kai Krakow wrote:
> >> Hello list!
> >
> > Hi list
>
> [kernel message snipped]
>
> >> Btrfs --repair refused to repair the filesystem telling me something
> >>
30 matches
Mail list logo
