On Fri, Sep 06, 2019 at 06:55:07PM +0200, Christoph Hellwig wrote:
> On Thu, Sep 05, 2019 at 10:06:50AM -0500, Goldwyn Rodrigues wrote:
> > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> > index 8321733c16c3..13495d8a1ee2 100644
> > --- a/fs/xfs/xfs_iomap.c
> > +++ b/fs/xfs/xfs_iomap.c
> >
On Fri, Sep 6, 2019 at 3:35 PM Chris Murphy wrote:
>
> On Fri, Sep 6, 2019 at 1:21 PM Rachel Sibley wrote:
> >
> > Hello,
> >
> > While running LTP [1] as part of CKI [2] testing, we noticed the fs_fill
> > test fails pretty
> > consistently with BTRFS warnings seen below, this is seen with recen
On Fri, Sep 6, 2019 at 1:21 PM Rachel Sibley wrote:
>
> Hello,
>
> While running LTP [1] as part of CKI [2] testing, we noticed the fs_fill
> test fails pretty
> consistently with BTRFS warnings seen below, this is seen with recent
> kernel (5.2.12).
> I have included the logs below for reference.
On Sat, Sep 07, 2019 at 07:07:17AM +1000, Dave Chinner wrote:
> On Fri, Sep 06, 2019 at 11:19:49AM -0700, Omar Sandoval wrote:
> > On Thu, Sep 05, 2019 at 12:10:12PM +1000, Dave Chinner wrote:
> > > On Wed, Sep 04, 2019 at 12:13:26PM -0700, Omar Sandoval wrote:
> > > > From: Omar Sandoval
> > > >
On Fri, Sep 06, 2019 at 11:19:49AM -0700, Omar Sandoval wrote:
> On Thu, Sep 05, 2019 at 12:10:12PM +1000, Dave Chinner wrote:
> > On Wed, Sep 04, 2019 at 12:13:26PM -0700, Omar Sandoval wrote:
> > > From: Omar Sandoval
> > >
> > > This adds an API for writing compressed data directly to the file
Hello,
While running LTP [1] as part of CKI [2] testing, we noticed the fs_fill
test fails pretty
consistently with BTRFS warnings seen below, this is seen with recent
kernel (5.2.12).
I have included the logs below for reference.
Thank you,
Rachel
*
https://artifacts.cki-project.org/pipeli
On Thu, Sep 05, 2019 at 12:10:12PM +1000, Dave Chinner wrote:
> On Wed, Sep 04, 2019 at 12:13:26PM -0700, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > This adds an API for writing compressed data directly to the filesystem.
> > The use case that I have in mind is send/receive: currently,
Hello, David.
On Thu, Sep 05, 2019 at 01:59:37PM +0200, David Sterba wrote:
> On Fri, Jul 26, 2019 at 05:13:21PM +0200, David Sterba wrote:
> > On Wed, Jul 10, 2019 at 12:28:13PM -0700, Tejun Heo wrote:
> > > Hello,
> > >
> > > This patchset contains only the btrfs part of the following patchset.
From: Mark Fasheh
No functional changes are made here, we simply move the backref cache out of
relocation.c and into it's own file, backref-cache.c. We also add the
headers relocation.h and backref-cache.h.
Signed-off-by: Mark Fasheh
---
fs/btrfs/Makefile|2 +-
fs/btrfs/backref-ca
From: Mark Fasheh
build_backref_tree() is walking extent refs in what is an otherwise self
contained chunk of code. We can shrink the total number of lines in
build_backref_tree() *and* make it more readable by moving that walk into
its own subroutine.
Signed-off-by: Mark Fasheh
---
fs/btrfs/
From: Mark Fasheh
The backref cache has to clean up nodes referring to tree leaves. It is
trivial to pull that code into it's own function, which is what I do here.
Signed-off-by: Mark Fasheh
---
fs/btrfs/backref-cache.c | 82 +++-
1 file changed, 47 inserti
Hi,
Relocation caches extent backrefs in an rbtree (the 'backref cache'). The
following patches move the backref cache code out of relocation.c and into
it's own file. We then do a straight-forward cleanup the main backref cache
function, build_backref_tree(). No functionality is changed in the
On Thu, Sep 05, 2019 at 10:06:50AM -0500, Goldwyn Rodrigues wrote:
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 8321733c16c3..13495d8a1ee2 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -1006,7 +1006,10 @@ xfs_file_iomap_begin(
>*/
>
On Tue, Sep 03, 2019 at 02:25:07PM +0530, Abdul Haleem wrote:
> Greeting's
>
> Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file
> system on my P9 box running mainline kernel 5.3.0-rc5
Is the issue reproducible? And if yes, how reliably? Thanks.
Use the return value of listxattr instead of tokenizing.
The end of the extended attribute list is indicated by the return
value, not an empty list item (two consecutive NULs). Using strtok
in this way thus sometimes caused add_xattr_item to reuse stack data
in xattr_list from the previous invocat
This is intended. Otherwise it's an open avenue for the user to shoot
themselves in the foot.
I don't understand how?
If you know what you are doing and are
absolutely sure the original fs is no longer present
- then just flush
libblkid cache and you'll be able to set the FSID back to
On Thu, Sep 05, 2019 at 02:16:37PM +0200, Johannes Thumshirn wrote:
> On 05/09/2019 04:10, Dave Chinner wrote:
> > On Wed, Sep 04, 2019 at 12:13:26PM -0700, Omar Sandoval wrote:
> >> From: Omar Sandoval
> >>
> >> This adds an API for writing compressed data directly to the filesystem.
> >> The use
On 6.09.19 г. 3:50 ч., Anand Jain wrote:
> It's common to copy/snapshot an OS image to run another instance of the OS.
> A duplicate fsid can't be mounted on the same system unless the fsid is
> changed by using btrfstune -m.
>
> However in some circumstances the image needs to go back to the o
18 matches
Mail list logo
