; +++ b/fs/inode.c
> @@ -397,7 +397,7 @@ void ihold(struct inode *inode)
> }
> EXPORT_SYMBOL(ihold);
>
> -static void inode_lru_list_add(struct inode *inode)
> +void inode_lru_list_add(struct inode *inode)
the inode lru list function can stay static.
Cheers,
Dave.
--
erences, but they don't replace
a properly written commit message.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ker
t;
> Cc: Ben Myers
> Cc: Alex Elder
> Cc: Dave Chinner
> Signed-off-by: "Eric W. Biederman"
> ---
.
> @@ -614,12 +627,12 @@ int
> xfs_qm_dqget(
> xfs_mount_t *mp,
> xfs_inode_t *ip, /* locked inode (optional) */
>
ly need to be staged through the XFS tree
given the complexity of the changes, the amount of validation that
is required. Also, it is likely that there are significant conflicts
against changes already staged for 3.8, so getting it upstream
through the XFS tree is the only option that I'd conside
;i_state & (I_DIRTY | I_FREEING | I_SYNC)) &&
> + !atomic_read(&inode->i_count) && inode->i_sb->s_flags & MS_ACTIVE)
> + inode_lru_list_add(inode);
Needs to avoid I_WILL_FREE as well. There's no point putting it on
the LRU if we are writing from iput_final(
rt of the event message has all the identifying
information where it is easy to grep for and get all the events for
a specific dev/inode combination without even having to think about
it.
XFS, ext3/4, jbd/jdb2 and gfs2 follow this convention, so we should
keep propagating that pattern in the name of
is special - it's only called
from generic_shutdown_super() after the MS_ACTIVE flag has been
removed from the filesytem, the dcache has been pruned and all the
inodes cleaned. So there should be no new references to the inodes
occurring, and hence we don't need to hold the lock to ser
ot sure that length isn't a better name than count for this
> function. What we want is the total length of the i/o request and count
> sounds to me as if it would refer to the number of segments. So could we
> have a iov_iter_length() function instead perhaps?
I had exactly the sa
ret = lo_discard(lo, bio);
> + goto out;
> + }
> + }
> +#ifdef CONFIG_AIO
> + if (lo->lo_flags & LO_FLAGS_USE_AIO &&
> + lo->transfer == transfer_none) {
> +
is
> > > > is a little harsh.
> > > >
> > > > Hm... looking at the ordered code a little more, it looks like
> > > > ext3_ordered_write_end is calling journal_dirty_data_fn, which (I
> > > > guess?) tries
> > > > to write mapped buffe
On Thu, Nov 22, 2012 at 12:51:00PM +0100, Robert Jarzmik wrote:
> Dave Chinner writes:
>
> > We actually have an informal convention for formating filesystem
> > trace events, and that is to use the device number
> >
> >>
> >> > +),
&g
fs: revert commit bbdd6808 to fallocate UAPI
From: Dave Chinner
Commit bbdd6808 ("fs: reserve fallocate flag codepoint") changes the
fallocate(2) syscall interface. The flag that is reserved by this
commit is for functionality that has previously been NAKed on the
-fsdevel mailing li
On Sun, Nov 25, 2012 at 09:55:20PM -0500, Theodore Ts'o wrote:
> On Mon, Nov 26, 2012 at 11:28:14AM +1100, Dave Chinner wrote:
> > fs: revert commit bbdd6808 to fallocate UAPI
> >
> > From: Dave Chinner
> >
> > Commit bbdd6808 ("fs: reserve fallocate f
e errors.
You should always feel free to ignore checkpatch warnings that make
no sense. I haven't used checkpatch now for several years - I
stopped using it when it got too noisy warning about uselesss,
trivial things in the XFS code base
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
-
On Wed, Dec 12, 2012 at 11:26:17AM +0100, Jan Kara wrote:
> On Wed 12-12-12 15:18:21, Dave Chinner wrote:
> > On Wed, Dec 12, 2012 at 03:31:37AM +0100, Jan Kara wrote:
> > > On Tue 11-12-12 16:44:15, Jeff Moyer wrote:
> > > > Jan Kara writes:
> > > >
&
On Fri, Dec 07, 2012 at 05:25:19PM +0530, Abhijit Pawar wrote:
> This patch replace the obsolete simple_strto with kstrto
The XFS changes look fine. Consider those:
Acked-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscri
ruption within a day of going upstream.
:)
Now to try to find the needle in very complex haystack. :/
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
where, though?
>
> ext3 requires snapshots; the rest are ok with either strategy.
>
> *If* snapshotting is generally liked, then yes I'll go redo it as a vfs mount
> option.
It's copying every single IO, right? If so, then please don't
propagate any further th
extra line of whitespace damage that doesn't
need to be there.
FWIW, could you write a test for xfstests for this behaviour
so we can confirm that we don't break it in future?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "uns
If all
you are trying to do is reduce the latency of the first read, then
only readahead the initial range that you are going to need to read...
Also, Pushing readahead off to a workqueue potentially allows
someone to DOS the system because readahead won't ever get throttled
in the syscall con
orce_page_cache_readahead), so should perform identically when
called in exactly the same manner...
But again, you are interesting in the latency of the first read of
16k from the file, but you are asking to readahead 1GB of data.
Perhaps your shoul dbe asking for readahead of something more
app
On Sun, Dec 16, 2012 at 03:04:42AM +, Eric Wong wrote:
> Dave Chinner wrote:
> > On Sat, Dec 15, 2012 at 12:54:48AM +, Eric Wong wrote:
> > > Applications streaming large files may want to reduce disk spinups and
> > > I/O latency by performing large am
On Sun, Dec 16, 2012 at 03:35:49AM +, Eric Wong wrote:
> Dave Chinner wrote:
> > On Sun, Dec 16, 2012 at 12:25:49AM +, Eric Wong wrote:
> > > Alan Cox wrote:
> > > > On Sat, 15 Dec 2012 00:54:48 +
> > > > Eric Wong wrote:
> > >
On Sun, Dec 16, 2012 at 03:59:53AM +, Eric Wong wrote:
> Dave Chinner wrote:
> > On Sun, Dec 16, 2012 at 03:04:42AM +, Eric Wong wrote:
> > > Dave Chinner wrote:
> > > > On Sat, Dec 15, 2012 at 12:54:48AM +, Eric Wong wrote:
> > > &g
On Sun, Dec 16, 2012 at 05:23:02AM +, Eric Wong wrote:
> Dave Chinner wrote:
> > On Sun, Dec 16, 2012 at 03:35:49AM +, Eric Wong wrote:
> > > Dave Chinner wrote:
> > > > On Sun, Dec 16, 2012 at 12:25:49AM +, Eric Wong wrote:
> > > > > Ala
On Wed, Sep 26, 2012 at 10:56:08AM +0800, Zhi Yong Wu wrote:
> On Tue, Sep 25, 2012 at 5:28 PM, Dave Chinner wrote:
> > On Sun, Sep 23, 2012 at 08:56:28PM +0800, zwu.ker...@gmail.com wrote:
> >> From: Zhi Yong Wu
> >>
> >> Introduce one new mount option &#x
On Wed, Sep 26, 2012 at 10:53:07AM +0800, Zhi Yong Wu wrote:
> On Tue, Sep 25, 2012 at 5:17 PM, Dave Chinner wrote:
> > On Sun, Sep 23, 2012 at 08:56:27PM +0800, zwu.ker...@gmail.com wrote:
> > I note that the code will always insert range items of a length
> > RANGE_SIZE.
index 7eb3b0c..0999d5c 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -1153,6 +1153,9 @@ mount_fs(struct file_system_type *type, int flags,
> const char *name, void *data)
> WARN_ON(sb->s_bdi == &default_backing_dev_info);
> sb->s_flags |=
to a
specific temperature. It is a *heat map*, not a hash list. i.e.
inode_heat_map, not heat_inode_hl. HEAT_MAP_SIZE, not HASH_SIZE.
As it is, there aren't any users of the heat maps that are generated
in this patch set - it's not even exported to userspace or to
debugfs, so I'm not sure h
{
> + start = mapping->writeback_index << PAGE_CACHE_SHIFT;
> + prev_count = (u64)wbc->nr_to_write;
> + }
Why only wbc->range_cyclic? This won't record things like
synchronous writes or fsync-triggered writes, are are far more
likely to be to
ove, and the other comments earlier in the series,
there's not a lot of point in me spending time commenting on ethe
code in detail here as it will change significantly as a result of
all the earlier comments
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this li
On Thu, Sep 27, 2012 at 02:23:16PM +0800, Zhi Yong Wu wrote:
> On Thu, Sep 27, 2012 at 11:43 AM, Dave Chinner wrote:
> > On Sun, Sep 23, 2012 at 08:56:30PM +0800, zwu.ker...@gmail.com wrote:
> >> From: Zhi Yong Wu
> >>
> >> Adds a hash table structure which
On Thu, Sep 27, 2012 at 02:28:12PM +0800, Zhi Yong Wu wrote:
> On Thu, Sep 27, 2012 at 11:54 AM, Dave Chinner wrote:
> > On Sun, Sep 23, 2012 at 08:56:31PM +0800, zwu.ker...@gmail.com wrote:
> >> From: Zhi Yong Wu
> >>
> >> Miscellaneous features that
On Thu, Sep 27, 2012 at 02:54:22PM +0800, Zhi Yong Wu wrote:
> On Thu, Sep 27, 2012 at 12:03 PM, Dave Chinner wrote:
> > On Sun, Sep 23, 2012 at 08:56:32PM +0800, zwu.ker...@gmail.com wrote:
> >> From: Zhi Yong Wu
> >>
> >> Fork and run one kernel kthrea
On Thu, Sep 27, 2012 at 01:25:34PM +0800, Zhi Yong Wu wrote:
> On Tue, Sep 25, 2012 at 5:28 PM, Dave Chinner wrote:
> > On Sun, Sep 23, 2012 at 08:56:28PM +0800, zwu.ker...@gmail.com wrote:
> >> From: Zhi Yong Wu
> >>
> >> Introduce one new mount option &#x
From: Dave Chinner
xfstests has always had random failures of tests due to loop devices
failing to be torn down and hence leaving filesytems that cannot be
unmounted. This causes test runs to immediately stop.
Over the past 6 or 7 years we've added hacks like explicit unmount
-d command
On Wed, Jan 16, 2013 at 11:21:44AM -0800, Glauber Costa wrote:
> On 11/27/2012 03:14 PM, Dave Chinner wrote:
> > From: Dave Chinner
> >
> > Now that we have an LRU list API, we can start to enhance the
> > implementation. This splits the single LRU list into per-
r per cache context, but the memcg code doesn't need
to duplicate the entire LRU infrastructure into every memcg that
contains that type of object for that cache context
/me stops rambling
> Your current suggestion of going per-node only in the performance
> critical files
to reclaim, the reclaim information passed tot eh
shrinker needs to indicate either the node to reclaim from or the
memcg_id (or both), so that reclaim can walk the appropriate list to
find objects to reclaim. Then we delete them from both lists and
reclaim the object
And the memcg lists can ins
On Thu, Jan 17, 2013 at 04:51:03PM -0800, Glauber Costa wrote:
> On 01/17/2013 04:10 PM, Dave Chinner wrote:
> > and we end up with:
> >
> > lru_add(struct lru_list *lru, struct lru_item *item)
> > {
> > node_id = min(object_to_nid(item), lru->numno
On Thu, Jan 17, 2013 at 04:14:10PM -0800, Glauber Costa wrote:
> On 01/17/2013 04:10 PM, Dave Chinner wrote:
> > And then each object uses:
> >
> > struct lru_item {
> > struct list_head global_list;
> > struct list_head memcg_list;
> > }
> by
On Fri, Jan 18, 2013 at 11:10:00AM -0800, Glauber Costa wrote:
> On 01/18/2013 12:11 AM, Dave Chinner wrote:
> > On Thu, Jan 17, 2013 at 04:14:10PM -0800, Glauber Costa wrote:
> >> On 01/17/2013 04:10 PM, Dave Chinner wrote:
> >>> And then each object use
changes
to these semaphores. They can be held for indeterminant periods of
time potentially across multiple disk I/Os (e.g. when held locked in
a transaction that requires more metadata to be read in from disk to
make progress). Hence there is no really no point in making them RT
aware because i
On Tue, Jul 19, 2016 at 02:22:47PM -0700, Calvin Owens wrote:
> On 07/18/2016 07:05 PM, Calvin Owens wrote:
> >On 07/17/2016 11:02 PM, Dave Chinner wrote:
> >>On Sun, Jul 17, 2016 at 10:00:03AM +1000, Dave Chinner wrote:
> >>>On Fri, Jul 15, 2016 at 05:18:
[PATCH] in the subject line don't get the immediate
attention of my mail filters, so I didn't see it immediately.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
e
remote.
So it's really only a per-cpu structure for list addition
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
5147] CR2: 0018
[ 16.535644] ---[ end trace 61a930b5078051b0 ]---
[ 16.535644] Kernel panic - not syncing: Fatal exception in interrupt
[ 16.535833] Kernel Offset: disabled
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Mon, Sep 26, 2016 at 09:22:45AM +1000, Dave Chinner wrote:
> Hi Folks,
>
> I just upgraded a test VM from 4.8-rc6 to 4.8-rc7, and went to run:
>
> # perf_4.7 top -g -U
>
> inside the VM - the kernel oops with the trace below. The perf
> binary was built from a 4.7
From: Dave Chinner
When building XFS with -Werror, it now fails with:
./include/linux/pagemap.h: In function ¿fault_in_multipages_readable¿:
./include/linux/pagemap.h:602:16: error: variable ¿c¿ set but not used
[-Werror=unused-but-set-variable]
volatile char c;
^
This is a
On Sun, Sep 25, 2016 at 06:21:05PM -0700, Linus Torvalds wrote:
> Thanks, applied.
>
> I did happen to notice:
>
> On Sun, Sep 25, 2016 at 4:57 PM, Dave Chinner wrote:
> >
> > ./include/linux/pagemap.h: In function ¿fault_in_multipages_readable¿:
> > ./incl
> > SCRATCH_MNT=SCRATCH \
> > ./check `grep -il freeze tests/*/???`
>
> You can run either:
>
> ./check -g freeze
>
> to check just the freezing tests or
>
> ./check
Better for regression testing is:
check -g auto
so that is skips all the tests that are broken or likely to crash
the machine on some debug check.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
it be better to put a comment mentioning this here? So as the
years go by, this reminds people not to bother trying to implement
it?
/*
* .pmd_fault is not supported for DAX because allocation in ext2
* cannot be reliably aligned to huge page sizes and so pmd faults
* will always fail and fail back to regular faults.
*/
--
Dave Chinner
da...@fromorbit.com
struct address_space *mapping = vma->vm_file->f_mapping;
> + unsigned long pmd_addr = address & PMD_MASK;
> + bool write = flags & FAULT_FLAG_WRITE;
> + struct inode *inode = mapping->host;
> + struct iomap iomap = { 0 };
> + int error, result = 0
that includes a "name"
field, have the shrinker callback fill it out appropriately. e.g
in the superblock shrinker:
trace_shrinker_callback(shrinker, shrink_control, sb->s_type->name);
And generic code that doesn't want to put a specific context name in
there can simply call:
trace_shrinker_callback(shrinker, shrink_control, __func__);
And now you know exactly what shrinker is being run.
No need to add names to any structures, it's call site defined so is
flexible, and if you're not using tracepoints has no overhead.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Thu, Jul 28, 2016 at 11:25:13AM +0100, Mel Gorman wrote:
> On Thu, Jul 28, 2016 at 03:49:47PM +1000, Dave Chinner wrote:
> > Seems you're all missing the obvious.
> >
> > Add a tracepoint for a shrinker callback that includes a "name"
> > fie
t;< (end_bit - bit)) - 1) << bit;
> *wordp |= mask;
> wordp++;
> bits_set = end_bit - bit;
This patch is whitespace damaged and fails to apply. I've fixed it
up as this is a trivial change. However, please fix the problem
before you submit more patches.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Tue, Sep 13, 2016 at 11:53:11AM +1000, Nicholas Piggin wrote:
> On Tue, 13 Sep 2016 07:34:36 +1000
> Dave Chinner wrote:
> But let me understand your example in the absence of that.
>
> - Application mmaps a file, faults in block 0
> - FS allocates block, creates mappin
On Wed, Sep 14, 2016 at 08:19:36PM +1000, Nicholas Piggin wrote:
> On Wed, 14 Sep 2016 17:39:02 +1000
> Dave Chinner wrote:
> > Ok, looking back over your example, you seem to be suggesting a new
> > page fault behaviour is required from filesystems that has not been
> >
On Wed, Sep 14, 2016 at 10:55:03PM -0700, Darrick J. Wong wrote:
> On Mon, Sep 12, 2016 at 11:40:35AM +1000, Dave Chinner wrote:
> > On Thu, Sep 08, 2016 at 04:56:36PM -0600, Ross Zwisler wrote:
> > > On Wed, Sep 07, 2016 at 09:32:36PM -0700, Dan Williams wrote:
> > > &g
On Thu, Sep 15, 2016 at 01:49:45PM +1000, Nicholas Piggin wrote:
> On Thu, 15 Sep 2016 12:31:33 +1000
> Dave Chinner wrote:
>
> > On Wed, Sep 14, 2016 at 08:19:36PM +1000, Nicholas Piggin wrote:
> > > On Wed, 14 Sep 2016 17:39:02 +1000
> > Sure, but one first has t
log done items directly in the deferred pending work item
Dave Chinner (1):
xfs: fix superblock inprogress check
fs/iomap.c | 5 -
fs/xfs/libxfs/xfs_alloc.c | 2 ++
fs/xfs/libxfs/xfs_btree.c | 14 +-
fs/xfs/libxfs/xfs_defer.c | 17 -
f
On Fri, Aug 19, 2016 at 04:08:34PM +0100, Mel Gorman wrote:
> On Thu, Aug 18, 2016 at 05:11:11PM +1000, Dave Chinner wrote:
> > On Thu, Aug 18, 2016 at 01:45:17AM +0100, Mel Gorman wrote:
> > > On Wed, Aug 17, 2016 at 04:49:07PM +0100, Mel Gorman wrote:
> > > > &g
On Thu, Aug 04, 2016 at 01:34:58PM +0100, Mel Gorman wrote:
> On Thu, Aug 04, 2016 at 01:24:09PM +0100, Mel Gorman wrote:
> > On Thu, Aug 04, 2016 at 03:10:51PM +1000, Dave Chinner wrote:
> > > Hi folks,
> > >
> > > I just noticed a whacky memory usage prof
On Fri, Aug 05, 2016 at 11:54:17AM +0100, Mel Gorman wrote:
> On Fri, Aug 05, 2016 at 09:11:10AM +1000, Dave Chinner wrote:
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index fb975cec3518..baa97da3687d 100644
> > > --- a/mm/page_alloc.c
> > >
On Fri, Aug 05, 2016 at 09:59:35PM +1000, Dave Chinner wrote:
> On Fri, Aug 05, 2016 at 11:54:17AM +0100, Mel Gorman wrote:
> > On Fri, Aug 05, 2016 at 09:11:10AM +1000, Dave Chinner wrote:
> > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > > index
create mode 100644 fs/xfs/libxfs/xfs_rmap_btree.h
create mode 100644 fs/xfs/xfs_rmap_item.c
create mode 100644 fs/xfs/xfs_rmap_item.h
create mode 100644 fs/xfs/xfs_trans_rmap.c
--
Dave Chinner
da...@fromorbit.com
n + 1;
> if (arraytop > context->firstu) {
> context->count = -1;/* insufficient space */
> + context->seen_enough = 1;
> return 0;
> }
> offset = (char *)context->alist + context->count;
Looks sane, though I don't know how to test it yet
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, Aug 24, 2016 at 10:08:33AM +0200, Artem Savkov wrote:
> On Wed, Aug 24, 2016 at 11:55:51AM +1000, Dave Chinner wrote:
> > On Tue, Aug 23, 2016 at 05:54:13PM +0200, Artem Savkov wrote:
> > > Commit "xfs: only return -errno or success from attr ->put_l
On Thu, Aug 25, 2016 at 10:21:09AM +0200, Artem Savkov wrote:
> On Thu, Aug 25, 2016 at 10:24:08AM +1000, Dave Chinner wrote:
> > On Wed, Aug 24, 2016 at 10:08:33AM +0200, Artem Savkov wrote:
> > > On Wed, Aug 24, 2016 at 11:55:51AM +1000, Dave Chinner wrote:
> > > >
On Mon, Jun 19, 2017 at 10:53:12PM -0700, Andy Lutomirski wrote:
> On Mon, Jun 19, 2017 at 5:46 PM, Dave Chinner wrote:
> > On Mon, Jun 19, 2017 at 08:22:10AM -0700, Andy Lutomirski wrote:
> >> Second: syncing extents. Here's a straw man. Forget the mmap() flag.
>
n.
However, we cannot guarantee that no writes occur to the inode with
immutable extent maps (especially as the whole point is to allow
userspace writes and commits without the kernel being involved), so
extent sharing on immutable extent maps cannot be allowed...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Tue, Jun 20, 2017 at 09:14:24AM -0700, Andy Lutomirski wrote:
> On Tue, Jun 20, 2017 at 3:11 AM, Dave Chinner wrote:
> > On Mon, Jun 19, 2017 at 10:53:12PM -0700, Andy Lutomirski wrote:
> >> On Mon, Jun 19, 2017 at 5:46 PM, Dave Chinner wrote:
> >> > On Mon, Ju
On Tue, Jun 20, 2017 at 06:24:03PM -0700, Darrick J. Wong wrote:
> On Wed, Jun 21, 2017 at 09:53:46AM +1000, Dave Chinner wrote:
> > On Tue, Jun 20, 2017 at 09:17:36AM -0700, Dan Williams wrote:
> > > An immutable-extent DAX-file and a reflink-capable DAX-file are not
> &
t; > +
> > +SYSCALL_DEFINE3(daxctl, const char __user *, path, int, flags, int, align)
>
> I was /about/ to grouse about this syscall, then realized that maybe it
> /is/ useful to be able to check a specific alignment. Maybe not, since
> I had something more permanent in mind anyway. In any case, just pass
> in an opened fd if this sticks around.
We can do all that via fallocate(), too...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Tue, Jun 20, 2017 at 10:18:24PM -0700, Andy Lutomirski wrote:
> On Tue, Jun 20, 2017 at 6:40 PM, Dave Chinner wrote:
> >> A per-inode
> >> count of the number of live DAX mappings or of the number of struct
> >> file instances that have requested DAX would work
On Tue, Oct 31, 2017 at 06:51:08PM -0700, Cong Wang wrote:
> On Mon, Oct 30, 2017 at 5:33 PM, Dave Chinner wrote:
> > On Mon, Oct 30, 2017 at 02:55:43PM -0700, Cong Wang wrote:
> >> Hello,
> >>
> >> We triggered a list corruption (double add) warning below on
On Tue, Oct 31, 2017 at 09:43:03PM -0700, Cong Wang wrote:
> On Tue, Oct 31, 2017 at 8:05 PM, Dave Chinner wrote:
> > On Tue, Oct 31, 2017 at 06:51:08PM -0700, Cong Wang wrote:
> >> >> Please let me know if I can provide any other information.
> >> >
>
On Wed, Nov 01, 2017 at 04:07:01PM +1100, Dave Chinner wrote:
> On Tue, Oct 31, 2017 at 09:43:03PM -0700, Cong Wang wrote:
> > On Tue, Oct 31, 2017 at 8:05 PM, Dave Chinner wrote:
> > > On Tue, Oct 31, 2017 at 06:51:08PM -0700, Cong Wang wrote:
> > >> >> Ple
[I missed this followup, other stuff]
On Mon, Oct 23, 2017 at 03:41:49PM +0200, Peter Zijlstra wrote:
> On Sat, Oct 21, 2017 at 10:21:11AM +1100, Dave Chinner wrote:
> > On Fri, Oct 20, 2017 at 02:07:53PM +0300, Elena Reshetova wrote:
> > IMO, that makes it way too hard to review
logwrite tests without
needing one-off test programs for them all...
> +#! /bin/bash
> +# FS QA Test No. 466
> +#
> +# Use md_log_writes to verify that MAP_SYNC actually syncs metadata during
dm_log_writes?
> +# We should see $SCRATCH_MNT/test as having 1MiB in block allocations
> +du -sh $SCRATCH_MNT/test | _filter_scratch | _filter_spaces
Perhaps stat -c %b $SCRATCH_MNT/test ?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
e refs to be dropped - so some form of busy extents. Am I
> > missing something?
> >
>
> No, that's a good summary of what we talked about. However, I did go
> back and give the new lock approach a try and was able to get my test
> to pass. The new locking is not pretty especially since you need to
> drop and reacquire the lock so that get_user_pages() can finish
> grabbing all the pages it needs. Here are the two primary patches in
> the series, do you think the extent-busy approach would be cleaner?
The XFS_DAXDMA
$DEITY that patch is so ugly I can't even bring myself to type it.
-Dave.
--
Dave Chinner
da...@fromorbit.com
On Tue, Nov 14, 2017 at 11:39:59AM +0800, Yu Chen wrote:
> Hi Dave,
> On Tue, Nov 14, 2017 at 09:52:16AM +1100, Dave Chinner wrote:
> > On Mon, Nov 13, 2017 at 06:31:39PM +0800, Yu Chen wrote:
> > > Hi all,
> > > Currently we are running hibernation stress test on a
in XFS forever. Now we've got to a
catch-22 situation that bandaids can't fix. We need structural
fixes, like I said we needed to do more than 10 years ago.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Tue, Nov 14, 2017 at 11:01:57PM +0100, Rafael J. Wysocki wrote:
> On Tuesday, November 14, 2017 10:25:38 PM CET Dave Chinner wrote:
> > On Tue, Nov 14, 2017 at 09:19:15PM +0100, Luis R. Rodriguez wrote:
> > > This is another way to say suspend has been busted on XFS for a ver
On Fri, Oct 27, 2017 at 01:42:16PM +0200, Dan Williams wrote:
> [replying from my phone, please forgive formatting]
>
> On Friday, October 27, 2017, Dave Chinner wrote:
>
>
> > > Here are the two primary patches in
> > > the series, do you think the exte
ree_extent -> xfs_extent_busy_insert(). That's probably the
most complex part of the patch.
This flag then prevents xfs_extent_busy_reuse() from allowing reuse
of the extent.
And in xfs_extent_busy_clear(), they need to be treated sort of like
discarded extents. On transaction commit callback, we need to check
if there are still busy daxdma pages over the extent range, and if
there are we leave it in the busy list, otherwise it can be cleared.
For everything that is left in the busy list, the dax dma code will
need to call back into the filesystem when that page is released and
when the extent no long has any dax dma busy pages left over it it
can be cleared from the list.
Once we have the dax code to call back into the filesystem when the
problematic daxdma pages are released, and everything else should be
relatively straight forward...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Mon, Oct 30, 2017 at 09:38:07AM +0100, Jan Kara wrote:
> Hi,
>
> On Mon 30-10-17 13:00:23, Dave Chinner wrote:
> > On Sun, Oct 29, 2017 at 04:46:44PM -0700, Dan Williams wrote:
> > > Coming back to this since Dave has made clear that new locking to
> > > coord
re would just
paper over whatever the underlying problem might be.
> Please let me know if I can provide any other information.
How do you reproduce the problem?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
, etc, that also need to be able to parse
and understand it. So while the xattr code can be made much more
generic, there's a bunch of filesystem specific code that needs to
go into multiple different repositories and userspace packages for
this.
Andreas, I also can't remember if any xfstests h
On Mon, Oct 05, 2015 at 07:02:21PM -0400, Waiman Long wrote:
> On 10/02/2015 06:16 PM, Dave Chinner wrote:
> >On Fri, Oct 02, 2015 at 01:29:57PM -0400, Waiman Long wrote:
> >>In __percpu_counter_compare(), if the current imprecise count is
> >>within (batch*nr_cpu
On Tue, Oct 06, 2015 at 12:01:19AM +0200, Andreas Gruenbacher wrote:
> On Mon, Oct 5, 2015 at 11:17 PM, Dave Chinner wrote:
> > On Mon, Oct 05, 2015 at 08:45:40PM +0200, Andreas Gruenbacher wrote:
> >> On Sun, Oct 4, 2015 at 8:23 AM, Christoph Hellwig
> >> wrote:
&g
to try to ensure that mapping related allocations do not cause
inappropriate reclaim contexts to be triggered.
This is a problem independent of any specific filesystem - let's not
hack a workaround into a specific filesystem just because the
problem was reported on that filesystem
Cheers,
On Mon, Oct 05, 2015 at 06:57:19PM -0700, Dan Williams wrote:
> On Wed, Sep 30, 2015 at 4:35 PM, Dave Chinner wrote:
> > On Tue, Sep 29, 2015 at 08:41:36PM -0400, Dan Williams wrote:
> >> +static void __pmem *__dax_map_bh(const struct buffer_head *bh, unsi
On Tue, Oct 06, 2015 at 01:33:21PM -0400, Waiman Long wrote:
> On 10/05/2015 08:25 PM, Dave Chinner wrote:
> >On Mon, Oct 05, 2015 at 07:02:21PM -0400, Waiman Long wrote:
> >
> >>>Having less than 1GB of free space in an XFS filesystem is
> >>>considere
On Wed, Oct 07, 2015 at 04:00:42PM -0400, Waiman Long wrote:
> On 10/06/2015 05:30 PM, Dave Chinner wrote:
> >>>/*
> >>> * Aggregate the per-cpu counter magazines back into the global
> >>> * counter. This avoids the need for repeated compare operations
On Wed, Oct 07, 2015 at 04:20:10PM -0700, Tejun Heo wrote:
> Hello, Dave.
>
> On Thu, Oct 08, 2015 at 10:04:42AM +1100, Dave Chinner wrote:
> ...
> > As it is, the update race you pointed out is easy to solve with
> > __this_cpu_cmpxchg rather than _this_cpu_sub (similar t
On Fri, Aug 28, 2015 at 08:54:04PM +0800, Gavin Guo wrote:
> On Wed, Jul 8, 2015 at 7:37 AM, Dave Chinner wrote:
> > On Tue, Jul 07, 2015 at 05:29:43PM +0800, Gavin Guo wrote:
> >> Hi all,
> >>
> >> Recently, we observed that there is the error message in
>
t, then I'm simply
going to revert it because having the tracing work correctly on
x86-64 is far more important to us than ppc64 or ia64
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
rite being called on the write and so
backing store is not allocated for the page, nor are the timestamps
for the file updated. This will also result in fsync (and msync)
not working properly.
Fix fsync first - if fsync works then msync will work.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.co
e forgotten that kernel-based, subsystem-independent memory reclaim
callbacks had existed for many, many years in other operating
systems before Linux re-invented them.
So, IMO, a shrinker implementation in a kernel module does not
automatically make the kernel module a derived work of the kernel.
401 - 500 of 2158 matches
Mail list logo
