At 03/09/2017 10:05 AM, Zygo Blaxell wrote:
On Wed, Mar 08, 2017 at 10:27:33AM +, Filipe Manana wrote:
On Wed, Mar 8, 2017 at 3:18 AM, Zygo Blaxell
wrote:
From: Zygo Blaxell
This is a story about 4 distinct (and very old) btrfs bugs.
Commit c8b978188c ("Btrfs: Add zlib compression sup
On Sun, Mar 19, 2017 at 07:18:59PM +0200, Alex Lyakas wrote:
> We have a commit_root_sem, which is a read-write semaphore that protects the
> commit roots.
> But it is also used to protect the list of caching block groups.
>
> As a result, while doing "slow" caching, the following issue is seen:
>
On Tue, 2017-03-21 at 15:13 -0400, J. Bruce Fields wrote:
> On Tue, Mar 21, 2017 at 02:46:53PM -0400, Jeff Layton wrote:
> > On Tue, 2017-03-21 at 14:30 -0400, J. Bruce Fields wrote:
> > > On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote:
> > > > On Tue, 2017-03-21 at 12:30 -0400, J. Bru
On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote:
> On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote:
> > - It's durable; the above comparison still works if there were reboots
> > between the two i_version checks.
> > - I don't know how realistic this is--we may need to fi
On Tue, Mar 21, 2017 at 02:46:53PM -0400, Jeff Layton wrote:
> On Tue, 2017-03-21 at 14:30 -0400, J. Bruce Fields wrote:
> > On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote:
> > > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote:
> > > > - It's durable; the above comparison stil
On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote:
> On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote:
> > - It's durable; the above comparison still works if there were reboots
> > between the two i_version checks.
> > - I don't know how realistic this is--we may need to fi
On Tue, 2017-03-21 at 14:30 -0400, J. Bruce Fields wrote:
> On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote:
> > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote:
> > > - It's durable; the above comparison still works if there were reboots
> > > between the two i_version check
On Tue, Mar 21, 2017 at 01:37:04PM -0400, J. Bruce Fields wrote:
> On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote:
> > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote:
> > > - NFS doesn't actually require that it increases, but I think it
> > > should. I assume 64 bits
On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote:
> On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote:
> > - NFS doesn't actually require that it increases, but I think it
> > should. I assume 64 bits means we don't need a discussion of
> > wraparound.
>
> I thou
On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote:
> On Tue, Mar 21, 2017 at 06:45:00AM -0700, Christoph Hellwig wrote:
> > On Mon, Mar 20, 2017 at 05:43:27PM -0400, J. Bruce Fields wrote:
> > > To me, the interesting question is whether this allows us to turn on
> > > i_version updates by d
On Tue, Mar 21, 2017 at 06:45:00AM -0700, Christoph Hellwig wrote:
> On Mon, Mar 20, 2017 at 05:43:27PM -0400, J. Bruce Fields wrote:
> > To me, the interesting question is whether this allows us to turn on
> > i_version updates by default on xfs and ext4.
>
> XFS v5 file systems have it on by def
On Mon, Mar 20, 2017 at 05:43:27PM -0400, J. Bruce Fields wrote:
> To me, the interesting question is whether this allows us to turn on
> i_version updates by default on xfs and ext4.
XFS v5 file systems have it on by default. Although we'll still need
to agree on the exact semantics of i_version
On Thu, Mar 16, 2017 at 05:08:51PM +0800, Qu Wenruo wrote:
> Btrfs balance will reloate date extent, but its hash is removed too late
^^^ relocate
> at run_delayed_ref() time, which will cause extent ref increased
> during balance, cause either find_data_references() gives
On Tue, Mar 21, 2017 at 03:36:54PM +0800, Qu Wenruo wrote:
>
>
> At 03/21/2017 03:23 PM, Eryu Guan wrote:
> > On Thu, Mar 16, 2017 at 09:50:24AM +0800, Qu Wenruo wrote:
> > > Btrfs in-band de-duplication test cases for in-memory backend, which
> > > covers
> > > the bugs exposed during the devel
At 03/21/2017 03:23 PM, Eryu Guan wrote:
On Thu, Mar 16, 2017 at 09:50:24AM +0800, Qu Wenruo wrote:
Btrfs in-band de-duplication test cases for in-memory backend, which covers
the bugs exposed during the development.
Sorry, I'm having trouble enabling inband dedupe in tests, I always get
ioc
On Thu, Mar 16, 2017 at 09:50:24AM +0800, Qu Wenruo wrote:
> Btrfs in-band de-duplication test cases for in-memory backend, which covers
> the bugs exposed during the development.
Sorry, I'm having trouble enabling inband dedupe in tests, I always get
ioctl failure, $seqres.full shows:
btrfs-prog
At 03/21/2017 02:05 PM, Eryu Guan wrote:
On Tue, Mar 21, 2017 at 01:22:33PM +0800, Qu Wenruo wrote:
At 03/21/2017 12:51 PM, Eryu Guan wrote:
Hi Qu,
On Thu, Mar 16, 2017 at 05:08:48PM +0800, Qu Wenruo wrote:
Btrfs in-band de-duplication test cases for in-memory backend, which covers
the bu
I read my question again, it was not perfectly clear, I am trying to
compile my own driver and not the btrfs module.
>From what I understand, it is considered "bad practice" in my driver
to make a call: btrfsInode = BTRFS_I(inode);
since it uses the internal btrfs API (in an outside driver such as
On Tue, Mar 21, 2017 at 10:23:56AM +0800, Qu Wenruo wrote:
>
>
> At 03/21/2017 10:08 AM, Liu Bo wrote:
> > On Tue, Mar 21, 2017 at 08:44:18AM +0800, Qu Wenruo wrote:
> > >
> > >
> > > At 03/21/2017 04:23 AM, Liu Bo wrote:
> > > > On Mon, Mar 20, 2017 at 02:21:48PM +0800, Qu Wenruo wrote:
> > >
At 03/21/2017 01:45 PM, Liu Bo wrote:
On Tue, Mar 21, 2017 at 10:23:56AM +0800, Qu Wenruo wrote:
At 03/21/2017 10:08 AM, Liu Bo wrote:
On Tue, Mar 21, 2017 at 08:44:18AM +0800, Qu Wenruo wrote:
At 03/21/2017 04:23 AM, Liu Bo wrote:
On Mon, Mar 20, 2017 at 02:21:48PM +0800, Qu Wenruo wro
20 matches
Mail list logo
