On Fri, Feb 15, 2019 at 1:57 AM Johannes Thumshirn wrote:
>
> (This is a joint proposal with Hannes Reinecke)
>
> Servers with NV-DIMM are slowly emerging in data centers but one key feature
> for reliability of these systems hasn't been addressed up to now, data
> redundancy.
>
> While it would b
On Fri, Feb 15, 2019 at 9:40 PM Dave Chinner wrote:
>
> On Sat, Feb 16, 2019 at 04:31:33PM +1100, Dave Chinner wrote:
> > On Fri, Feb 15, 2019 at 10:57:12AM +0100, Johannes Thumshirn wrote:
> > > (This is a joint proposal with Hannes Reinecke)
> > >
> > > Servers with NV-DIMM are slowly emerging i
On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong wrote:
>
> On Fri, Feb 26, 2021 at 09:45:45AM +, ruansy.f...@fujitsu.com wrote:
> > Hi, guys
> >
> > Beside this patchset, I'd like to confirm something about the
> > "EXPERIMENTAL" tag for dax in XFS.
> >
> > In XFS, the "EXPERIMENTAL" tag, whi
On Fri, Feb 26, 2021 at 12:51 PM Dave Chinner wrote:
>
> On Fri, Feb 26, 2021 at 11:24:53AM -0800, Dan Williams wrote:
> > On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong wrote:
> > >
> > > On Fri, Feb 26, 2021 at 09:45:45AM +, ruansy.f...@fujit
On Fri, Feb 26, 2021 at 1:28 PM Dave Chinner wrote:
>
> On Fri, Feb 26, 2021 at 12:59:53PM -0800, Dan Williams wrote:
> > On Fri, Feb 26, 2021 at 12:51 PM Dave Chinner wrote:
> > >
> > > On Fri, Feb 26, 2021 at 11:24:53AM -0800, Dan Williams wrote:
> >
On Sat, Feb 27, 2021 at 2:36 PM Dave Chinner wrote:
>
> On Fri, Feb 26, 2021 at 02:41:34PM -0800, Dan Williams wrote:
> > On Fri, Feb 26, 2021 at 1:28 PM Dave Chinner wrote:
> > > On Fri, Feb 26, 2021 at 12:59:53PM -0800, Dan Williams wrote:
> > > > On Fri, Feb
On Sun, Feb 28, 2021 at 2:39 PM Dave Chinner wrote:
>
> On Sat, Feb 27, 2021 at 03:40:24PM -0800, Dan Williams wrote:
> > On Sat, Feb 27, 2021 at 2:36 PM Dave Chinner wrote:
> > > On Fri, Feb 26, 2021 at 02:41:34PM -0800, Dan Williams wrote:
> > > > On Fri, Feb
On Sun, Feb 28, 2021 at 11:27 PM Yasunori Goto wrote:
>
> Hello, Dan-san,
>
> On 2021/02/27 4:24, Dan Williams wrote:
> > On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong wrote:
> >>
> >> On Fri, Feb 26, 2021 at 09:45:45AM +, ruansy.f...@fujitsu.com wrot
On Mon, Mar 1, 2021 at 2:47 PM Dave Chinner wrote:
>
> On Mon, Mar 01, 2021 at 12:55:53PM -0800, Dan Williams wrote:
> > On Sun, Feb 28, 2021 at 2:39 PM Dave Chinner wrote:
> > >
> > > On Sat, Feb 27, 2021 at 03:40:24PM -0800, Dan Williams wrote:
> > >
On Mon, Mar 1, 2021 at 6:42 PM Dave Chinner wrote:
[..]
> We do not need a DAX specific mechanism to tell us "DAX device
> gone", we need a generic block device interface that tells us "range
> of block device is gone".
This is the crux of the disagreement. The block_device is going away
*and* th
On Mon, Mar 1, 2021 at 7:28 PM Darrick J. Wong wrote:
>
> On Mon, Mar 01, 2021 at 12:55:53PM -0800, Dan Williams wrote:
> > On Sun, Feb 28, 2021 at 2:39 PM Dave Chinner wrote:
> > >
> > > On Sat, Feb 27, 2021 at 03:40:24PM -0800, Dan Williams wrote:
> > >
On Mon, Mar 1, 2021 at 9:38 PM Dave Chinner wrote:
>
> On Mon, Mar 01, 2021 at 07:33:28PM -0800, Dan Williams wrote:
> > On Mon, Mar 1, 2021 at 6:42 PM Dave Chinner wrote:
> > [..]
> > > We do not need a DAX specific mechanism to tell us "DAX device
> > &
On Mon, Mar 1, 2021 at 11:57 PM Dave Chinner wrote:
>
> On Mon, Mar 01, 2021 at 09:41:02PM -0800, Dan Williams wrote:
> > On Mon, Mar 1, 2021 at 7:28 PM Darrick J. Wong wrote:
> > > > > I really don't see you seem to be telling us that invalidation is an
> >
On Wed, Mar 10, 2021 at 6:27 AM Matthew Wilcox wrote:
>
> On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote:
> > On 13:02 10/03, Matthew Wilcox wrote:
> > > On Wed, Mar 10, 2021 at 07:30:41AM -0500, Neal Gompa wrote:
> > > > Forgive my ignorance, but is there a reason why this isn'
On Mon, Feb 18, 2019 at 2:50 AM Johannes Thumshirn wrote:
>
> On 16/02/2019 06:39, Dave Chinner wrote:
> [..]
>
> >> We've supported this since mid 2018 and commit ba23cba9b3bd ("fs:
> >> allow per-device dax status checking for filesystems"). That is,
> >> we can have DAX on the XFS RT device ind
On Wed, Dec 5, 2018 at 4:29 AM Goldwyn Rodrigues wrote:
>
> From: Goldwyn Rodrigues
>
> These functions are required for btrfs dax support.
>
> Signed-off-by: Goldwyn Rodrigues
> ---
> fs/dax.c| 35 ---
> include/linux/dax.h | 16
> 2
changes up to 1f19b983a8877f81763fab3e693c6befe212736d:
libnvdimm, namespace: fix pmem namespace leak, delete when size set
to zero (2017-01-13 09:50:33 -0800)
Dan Williams (1):
libnvdimm, namespace: fix pmem namespace leak
in this case the initial user is dax-fsync where the
->get_bdev() answer should be static for the life of the inode, and
btrfs does not currently interface with dax. But yes, we need to get
the expected semantics clear.
On Tue, Feb 2, 2016 at 3:38 PM, Dan Williams wrote:
> [ addi
On Mon, Jul 13, 2009 at 7:11 AM, David Woodhouse wrote:
> We'll want to use these in btrfs too.
>
> Signed-off-by: David Woodhouse
Do you suspect that btrfs will also want to perform these operations
asynchronously? I am preparing an updated release of the raid6
offload patch kit, but the previo
On Wed, Jul 15, 2009 at 1:16 PM, Chris Mason wrote:
> On Wed, Jul 15, 2009 at 12:23:47PM -0700, Dan Williams wrote:
>> On Mon, Jul 13, 2009 at 7:11 AM, David Woodhouse wrote:
>> > We'll want to use these in btrfs too.
>> >
>> > Signed-off-by: David Woodho
On Sat, Jul 18, 2009 at 4:53 AM, David Woodhouse wrote:
> On Fri, 2009-07-17 at 11:49 -0400, H. Peter Anvin wrote:
>> Cost, yes, of changing an on-disk format.
>
> Personally, I don't care about that -- I'm utterly uninterested in the
> legacy RAID-6 setup where it pretends to be a normal disk. I t
On Sat, Jul 18, 2009 at 11:42 AM, David Woodhouse wrote:
> On Sat, 18 Jul 2009, Dan Williams wrote:
>> I was under the impression that btrfs wanted to leverage md's stripe
>> handling logic as well, seems that is not the case?
>
> No. We do a bunch of the stuff you m
On Thu, Aug 6, 2009 at 3:17 AM, David Woodhouse wrote:
> If we've abandoned the idea of putting the number of redundant blocks
> into the top bits of the type bitmask (and I hope we have), then we're
> fairly much there. Current code is at:
>
> git://, http://git.infradead.org/users/dwmw2/btrfs-
. I do not think we need any more experimentation
before declaring the current implementation broken.
---
Dan Williams (2):
btrq: uplevel the btrfs thread pool for md/raid456 usage
md/raid456: switch to btrq for multicore operation
drivers/md/Kconfig |1
drivers
The current async thread pool is optimized for extracting subsystem init
parallelism. The btrfs workqueue is targetted for load balancing high
cpu utilization works and is a better candidate for a raid thread pool.
---
fs/btrfs/Kconfig |1
fs/btrfs/Makefile|2 -
fs/btrfs
The btrfs workqueue is designed for load balancing cpu intensive
operations. Reuse it in md/raid456 for distributing stripe processing
across multiple cores.
---
drivers/md/Kconfig |1 +
drivers/md/raid5.c | 79 ++--
drivers/md/raid5.h | 13
On Wed, Mar 24, 2010 at 8:51 AM, Chris Mason wrote:
> On Wed, Mar 24, 2010 at 07:53:10AM -0700, Dan Williams wrote:
>> The current implementation with the async thread pool ends up spreading
>> the work over too many threads. The btrfs workqueue is targeted at high
>> cpu
27 matches
Mail list logo
