| To: | Dave Chinner <david@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: Failing XFS memory allocation |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Thu, 24 Mar 2016 02:31:27 -0700 |
| Cc: | Brian Foster <bfoster@xxxxxxxxxx>, Nikolay Borisov <kernel@xxxxxxxx>, xfs@xxxxxxxxxxx |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20160323230002.GY30721@dastard> |
| References: | <56F26CCE.6010502@xxxxxxxx> <20160323124312.GB43073@xxxxxxxxxxxxxxx> <56F29279.70600@xxxxxxxx> <20160323131059.GC43073@xxxxxxxxxxxxxxx> <20160323230002.GY30721@dastard> |
| User-agent: | Mutt/1.5.24 (2015-08-30) |
On Thu, Mar 24, 2016 at 10:00:02AM +1100, Dave Chinner wrote: > I'm working on prototype patches to convert it to an in-memory btree > but they are far from ready at this point. This isn't straight > forward because all the extent management code assumes extents are > kept in a linear array and can be directly indexed by array offset > rather than file offset. I also want to make sure we can demand page > the extent list if necessary, and that also complicates things like > locking, as we currently assume the extent list is either completely > in memory or not in memory at all. FYI, I did patches to get rid almost all direct extent array access a while ago, but I never bothered to post it as it seemed to much churn. Have you started that work yet or would it be useful to dust those up again? |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Failing XFS memory allocation, Nikolay Borisov |
|---|---|
| Next by Date: | Re: Failing XFS memory allocation, Christoph Hellwig |
| Previous by Thread: | Re: Failing XFS memory allocation, Dave Chinner |
| Next by Thread: | Re: Failing XFS memory allocation, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |