Re: inode leak in 2.6.24?

On Wed, Feb 20, 2008 at 03:36:53PM +0100, Ferenc Wagner wrote: > David Chinner <[EMAIL PROTECTED]> writes: > > The xfs inodes are clearly pinned by the dentry cache, so the issue > > is dentries, not inodes. What's causing dentries not to be > > reclaimed? I can&#

Re: inode leak in 2.6.24?

On Tue, Feb 19, 2008 at 05:57:08PM +0100, Ferenc Wagner wrote: > David Chinner <[EMAIL PROTECTED]> writes: > > On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote: > So, I loaded the same kernel on a different machine, but that seems to > exhibit a very similar behav

Re: [PATCH] Implement barrier support for single device DM devices

On Tue, Feb 19, 2008 at 02:39:00AM +, Alasdair G Kergon wrote: > > For example, how safe > > xfs is if barriers are not supported or turned off? > > The last time we tried xfs with dm it didn't seem to notice -EOPNOTSUPP > everywhere it should => recovery may find corruption. Bug reports, p

Re: xfsaild causing 30+ wakeups/s on an idle system since 2.6.25-rcX

On Mon, Feb 18, 2008 at 03:22:02PM -0800, Linda Walsh wrote: > Not to look excessively dumb, but what's xfsaild? AIL = Active Item List It is a sorted list all the logged metadata objects that have not yet been written back to disk. The xfsaild is responsible for tail pushing the log. i.e. wri

Re: [dm-devel] Re: [PATCH] Implement barrier support for single device DM devices

On Tue, Feb 19, 2008 at 02:56:43AM +, Alasdair G Kergon wrote: > On Tue, Feb 19, 2008 at 09:16:44AM +1100, David Chinner wrote: > > Surely any hardware that doesn't support barrier > > operations can emulate them with cache flushes when they receive a > > barri

Re: [dm-devel] Re: [PATCH] Implement barrier support for single device DM devices

On Mon, Feb 18, 2008 at 04:24:27PM +0300, Michael Tokarev wrote: > First, I still don't understand why in God's sake barriers are "working" > while regular cache flushes are not. Almost no consumer-grade hard drive > supports write barriers, but they all support regular cache flushes, and > the la

Re: inode leak in 2.6.24?

On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote: > Hi, > > 5 days ago I pulled the git tree (HEAD was > 25f666300625d894ebe04bac2b4b3aadb907c861), added two minor patches > (the vmsplice fix and the GFS1 exports), compiled and booted the > kernel. Things are working OK, but I notice

Re: xfsaild causing 30+ wakeups/s on an idle system since 2.6.25-rcX

On Mon, Feb 18, 2008 at 11:41:39AM +0200, Török Edwin wrote: > David Chinner wrote: > > On Sun, Feb 17, 2008 at 05:51:08PM +0100, Oliver Pinter wrote: > > > >> On 2/17/08, Török Edwin <[EMAIL PROTECTED]> wrote: > >> > >>> Hi, &

Re: [PATCH] Implement barrier support for single device DM devices

On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote: > Alasdair G Kergon wrote: > > On Fri, Feb 15, 2008 at 01:08:21PM +0100, Andi Kleen wrote: > >> Implement barrier support for single device DM devices > > > > Thanks. We've got some (more-invasive) dm patches in the works that > >

Re: xfsaild causing 30+ wakeups/s on an idle system since 2.6.25-rcX

On Sun, Feb 17, 2008 at 05:51:08PM +0100, Oliver Pinter wrote: > On 2/17/08, Török Edwin <[EMAIL PROTECTED]> wrote: > > Hi, > > > > xfsaild is causing many wakeups, a quick investigation shows > > xfsaild_push is always > > returning 30 msecs timeout value. That's a bug, and has nothing to do with

Re: linux-next: first tree

On Fri, Feb 15, 2008 at 11:50:40AM +1100, Stephen Rothwell wrote: > Hi David, > > On Fri, 15 Feb 2008 10:17:02 +1100 David Chinner <[EMAIL PROTECTED]> wrote: > > > > The current XFS tree that goes into -mm is: > > > > git://oss.sgi.com:8090/xfs/xfs-2.6.git

Re: linux-next: first tree

On Fri, Feb 15, 2008 at 12:35:37AM +1100, Stephen Rothwell wrote: > Also, more trees please ... :-) The current XFS tree that goes into -mm is: git://oss.sgi.com:8090/xfs/xfs-2.6.git master Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- To unsubscribe from th

Re: xfs [_fsr] probs in 2.6.24.0

On Tue, Feb 12, 2008 at 01:02:05PM -0800, Linda Walsh wrote: > David Chinner wrote: > >Perhaps by running xfs_fsr manually you could reproduce the > >problem while you are sitting in front of the machine... > > Um...yeah, AND with multiple "cp's of mul

Re: xfs [_fsr] probs in 2.6.24.0

On Mon, Feb 11, 2008 at 05:02:05PM -0800, Linda Walsh wrote: > > I'm getting similar errors on an x86-32 & x86-64 kernel. The x86-64 system > (2nd log below w/date+times) was unusable this morning: one or more of the > xfs file systems had "gone off line" due to some unknown error (upon reboot, >

Re: [PATCH] xfs: convert beX_add to beX_add_cpu (new common API)

On Sun, Feb 10, 2008 at 11:18:09AM +0100, Marcin Slusarz wrote: > This patch was in Andrew tree, but it was uncomplete. > Here is updated version. > > --- > remove beX_add functions and replace all uses with beX_add_cpu > > Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]> > --- Looks good. You c

Re: IO queuing and complete affinity with threads (was Re: [PATCH 0/8] IO queuing and complete affinity)

On Fri, Feb 08, 2008 at 08:59:55AM +0100, Jens Axboe wrote: > > > > At least they reported it to be the most efficient scheme in their > > > > testing, and Dave thought that migrating completions out to submitters > > > > might be a bottleneck in some cases. > > > > > > More so than migrating subm

Re: [stable] [patch 00/45] 2.6.24-stable review

On Thu, Feb 07, 2008 at 05:12:30PM -0800, Greg KH wrote: > On Fri, Feb 08, 2008 at 11:44:30AM +1100, David Chinner wrote: > > Greg, > > > > Is there any reason why the XFS patch I sent to the stable list a > > couple of days ago is not included in this series? > >

Re: [patch 00/45] 2.6.24-stable review

Greg, Is there any reason why the XFS patch I sent to the stable list a couple of days ago is not included in this series? http://oss.sgi.com/archives/xfs/2008-02/msg00027.html We've had multiple reports of it, and multiple confirmations that the patch in the link above fixes the problem. C

Re: remount-ro & umount & quota interaction

On Thu, Feb 07, 2008 at 03:10:18PM +0100, Jan Engelhardt wrote: > > On Feb 7 2008 15:04, Jan Kara wrote: > >On Thu 07-02-08 13:49:52, Michael Tokarev wrote: > >> Jan Kara wrote: > >> [deadlock after remount-ro followed with umount when > >> quota is enabled] > >> > >> Hmm. While that will preve

Re: [rfc] direct IO submission and completion scalability issues

On Mon, Feb 04, 2008 at 11:09:59AM +0100, Nick Piggin wrote: > You get better behaviour in the slab and page allocators and locality > and cache hotness of memory. For example, I guess in a filesystem / > pagecache heavy workload, you have to touch each struct page, buffer head, > fs private state,

Re: [rfc] direct IO submission and completion scalability issues

On Sun, Feb 03, 2008 at 08:14:45PM -0800, Arjan van de Ven wrote: > David Chinner wrote: > >Hi Nick, > > > >When Matthew was describing this work at an LCA presentation (not > >sure whether you were at that presentation or not), Zach came up > >with the

Re: [rfc] direct IO submission and completion scalability issues

On Sun, Feb 03, 2008 at 10:52:52AM +0100, Nick Piggin wrote: > On Fri, Jul 27, 2007 at 06:21:28PM -0700, Suresh B wrote: > > > > Second experiment which we did was migrating the IO submission to the > > IO completion cpu. Instead of submitting the IO on the same cpu where the > > request arrived,

Re: XFS oops in vanilla 2.6.24

On Thu, Jan 31, 2008 at 12:23:11PM +0100, Peter Zijlstra wrote: > Lets CC the XFS maintainer.. Adding the xfs list and hch. It might be a couple of days before I get to this - I've got a week of backlog to catch up on after LCA > On Wed, 2008-01-30 at 20:23 +, Sven Geggus wrote: > > Hi t

Re: [RFC] ext3 freeze feature

On Sat, Jan 26, 2008 at 04:35:26PM +1100, David Chinner wrote: > On Fri, Jan 25, 2008 at 07:59:38PM +0900, Takashi Sato wrote: > > The points of the implementation are followings. > > - Add calls of the freeze function (freeze_bdev) and > > the unfreeze function (tha

Re: [RFC] ext3 freeze feature

On Fri, Jan 25, 2008 at 07:59:38PM +0900, Takashi Sato wrote: > The points of the implementation are followings. > - Add calls of the freeze function (freeze_bdev) and > the unfreeze function (thaw_bdev) in ext3_ioctl(). > > - ext3_freeze_timeout() which calls the unfreeze function (thaw_bdev) >

Re: [RFC] ext3 freeze feature

On Fri, Jan 25, 2008 at 09:42:30PM +0900, Takashi Sato wrote: > >I am also wondering whether we should have system call(s) for these: > > > >On Jan 25, 2008 12:59 PM, Takashi Sato <[EMAIL PROTECTED]> wrote: > >>+ case EXT3_IOC_FREEZE: { > > > >>+ case EXT3_IOC_THAW: { > > > >And just co

Re: [patch 01/26] mount options: add documentation

> In message <[EMAIL PROTECTED]>, Miklos Szeredi writes: > > From: Miklos Szeredi <[EMAIL PROTECTED]> > > > > This series addresses the problem of showing mount options in > > /proc/mounts. [...] > > The following filesystems still need fixing: CIFS, NFS, XFS, Unionfs, > > Reiser4. For CIFS, NFS

Re: do_remount_sb(RDONLY) race? (was: XFS oops under 2.6.23.9)

On Wed, Jan 23, 2008 at 04:24:33PM +1030, Jonathan Woithe wrote: > > On Wed, Jan 23, 2008 at 03:00:48PM +1030, Jonathan Woithe wrote: > > > Last night my laptop suffered an oops during closedown. The full oops > > > reports can be downloaded from > > > > > > http://www.atrad.com.au/~jwoithe/xfs

do_remount_sb(RDONLY) race? (was: XFS oops under 2.6.23.9)

On Wed, Jan 23, 2008 at 03:00:48PM +1030, Jonathan Woithe wrote: > Last night my laptop suffered an oops during closedown. The full oops > reports can be downloaded from > > http://www.atrad.com.au/~jwoithe/xfs_oops/ Assertion failed: atomic_read(&mp->m_active_trans) == 0, file: fs/xfs/xfs_vfs

Re: [PATCH 0/6] IO context sharing

On Tue, Jan 22, 2008 at 10:49:15AM +0100, Jens Axboe wrote: > Hi, > > Today io contexts are per-process and define the (surprise) io context > of that process. In some situations it would be handy if several > processes share an IO context. I think that the nfsd threads should probably share as w

Re: [RFC] Parallelize IO for e2fsck

On Tue, Jan 22, 2008 at 12:05:11AM -0700, Andreas Dilger wrote: > On Jan 22, 2008 14:38 +1100, David Chinner wrote: > > On Mon, Jan 21, 2008 at 04:00:41PM -0700, Andreas Dilger wrote: > > > I discussed this with Ted at one point also. This is a generic problem, > >

Re: [RFC] Parallelize IO for e2fsck

On Mon, Jan 21, 2008 at 04:00:41PM -0700, Andreas Dilger wrote: > On Jan 16, 2008 13:30 -0800, Valerie Henson wrote: > > I have a partial solution that sort of blindly manages the buffer > > cache. First, the user passes e2fsck a parameter saying how much > > memory is available as buffer cache.

Re: 2.6.24-rc8: possible circular locking dependency detected

On Fri, Jan 18, 2008 at 10:45:17PM +0100, Christian Kujau wrote: > Hi, > > just FYI, upgrading to -rc8 gave the following messages in kern.log in > the morning hours, when the backups were run: > > === > [ INFO: possible circular locking depende

Re: [patch] Converting writeback linked lists to a tree based data structure

On Fri, Jan 18, 2008 at 01:41:33PM +0800, Fengguang Wu wrote: > > That is, think of large file writes like process scheduler batch > > jobs - bulk throughput is what matters, so the larger the time slice > > you give them the higher the throughput. > > > > IMO, the sort of result we should be look

Re: [patch] Converting writeback linked lists to a tree based data structure

On Thu, Jan 17, 2008 at 09:38:24PM -0800, Michael Rubin wrote: > On Jan 17, 2008 9:01 PM, David Chinner <[EMAIL PROTECTED]> wrote: > > First off thank you for the very detailed reply. This rocks and gives > me much to think about. > > > On Thu, Jan 17, 2008 at 01:0

Re: [patch] Converting writeback linked lists to a tree based data structure

On Thu, Jan 17, 2008 at 01:07:05PM -0800, Michael Rubin wrote: > > Michael, could you sort out and document the new starvation prevention > > schemes? > > The basic idea behind the writeback algorithm to handle starvation. > The over arching idea is that we want to preserve order of writeback > b

Re: [RFC] Parallelize IO for e2fsck

On Wed, Jan 16, 2008 at 01:30:43PM -0800, Valerie Henson wrote: > Hi y'all, > > This is a request for comments on the rewrite of the e2fsck IO > parallelization patches I sent out a few months ago. The mechanism is > totally different. Previously IO was parallelized by issuing IOs from > multipl

Re: [patch] Converting writeback linked lists to a tree based data structure

On Thu, Jan 17, 2008 at 11:16:00AM +0800, Fengguang Wu wrote: > On Thu, Jan 17, 2008 at 09:35:10AM +1100, David Chinner wrote: > > On Wed, Jan 16, 2008 at 05:07:20PM +0800, Fengguang Wu wrote: > > > On Tue, Jan 15, 2008 at 09:51:49PM -0800, Andrew Morton wrote: > > > >

Re: [patch] Converting writeback linked lists to a tree based data structure

On Wed, Jan 16, 2008 at 05:07:20PM +0800, Fengguang Wu wrote: > On Tue, Jan 15, 2008 at 09:51:49PM -0800, Andrew Morton wrote: > > > Then to do better ordering by adopting radix tree(or rbtree > > > if radix tree is not enough), > > > > ordering of what? > > Switch from time to location. Note th

Re: [PATCH 09/13] writeback: requeue_io() on redirtied inode

On Tue, Jan 15, 2008 at 08:36:46PM +0800, Fengguang Wu wrote: > Redirtied inodes could be seen in really fast writes. > They should really be synced as soon as possible. > > redirty_tail() could delay the inode for up to 30s. > Kill the delay by using requeue_io() instead. That's actually bad for

Re: [patch] Converting writeback linked lists to a tree based data structure

On Tue, Jan 15, 2008 at 07:44:15PM -0800, Andrew Morton wrote: > On Wed, 16 Jan 2008 11:01:08 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote: > > > On Tue, Jan 15, 2008 at 09:53:42AM -0800, Michael Rubin wrote: > > > On Jan 15, 2008 12:46 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > > Just a

Re: [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck)

On Tue, Jan 15, 2008 at 09:16:53PM +0100, Pavel Machek wrote: > Hi! > > > > What are ext3 expectations of disk (is there doc somewhere)? For > > > example... if disk does not lie, but powerfail during write damages > > > the sector -- is ext3 still going to work properly? > > > > Nope. However th

Re: Why is deleting (or reading) files not counted as IO-Wait in top?

On Wed, Jan 02, 2008 at 08:35:03PM +0100, Matthias Schniedermeyer wrote: > Hi > > > Currently i'm deleting about 500.000 files on a XFS-filesystem which > takes a few minutes, as i had a top open i saw that 'wa' is shown as > 0.0% (Nothing else running currently) and everything except 'id' is n

Re: xfs|loop|raid: attempt to access beyond end of device

On Sun, Dec 23, 2007 at 08:21:08PM +0100, Janos Haar wrote: > Hello, list, > > I have a little problem on one of my productive system. > > The system sometimes crashed, like this: > > Dec 23 08:53:05 Albohacen-global kernel: attempt to access beyond end of > device > Dec 23 08:53:05 Albohacen-gl

Re: [ia64] BUG: sleeping in atomic

On Wed, Dec 19, 2007 at 11:42:04AM -0500, Kyle McMartin wrote: > On Wed, Dec 19, 2007 at 04:54:30PM +1100, David Chinner wrote: > > [ 5667.086055] BUG: sleeping function called from invalid context at > > kernel/fork.c:401 > > > > The problem is that mmput is ca

Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning

On Thu, Dec 20, 2007 at 11:07:01AM +1100, James Morris wrote: > On Wed, 19 Dec 2007, David Chinner wrote: > > > Folks, > > > > I just updated a git tree and started getting errors on a > > "copy_keys" macro warning. > > > > The code

Re: Important regression with XFS update for 2.6.24-rc6

On Wed, Dec 19, 2007 at 12:17:30PM +0100, Damien Wyart wrote: > * David Chinner <[EMAIL PROTECTED]> [071219 11:45]: > > Can someone pass me a brown paper bag, please? > > My first impression on this bug was not so wrong, after all ;-) > > > That also explains why we

Re: Important regression with XFS update for 2.6.24-rc6

On Wed, Dec 19, 2007 at 02:19:47AM +1100, David Chinner wrote: > On Tue, Dec 18, 2007 at 03:30:31PM +0100, Damien Wyart wrote: > > * David Chinner <[EMAIL PROTECTED]> [071218 13:24]: > > > Ok. I haven't noticed anything wrong with directories up to about > > &

[patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning

Folks, I just updated a git tree and started getting errors on a "copy_keys" macro warning. The code I've been working on uses a ->copy_keys() method for copying the keys in a btree block from one place to another. I've been working on this code for a while (http://oss.sgi.com/archives/xfs/2007-1

[ia64] BUG: sleeping in atomic

Just saw this again: [ 5667.086055] BUG: sleeping function called from invalid context at kernel/fork.c:401 [ 5667.087314] in_atomic():1, irqs_disabled():0 [ 5667.088210] [ 5667.088212] Call Trace: [ 5667.089104] [] show_stack+0x80/0xa0 [ 5667.089106] sp=e038f

Re: [GIT PULL] XFS update for 2.6.24-rc6

On Tue, Dec 18, 2007 at 05:19:04PM -0800, Linus Torvalds wrote: > > > On Wed, 19 Dec 2007, David Chinner wrote: > > > > On Tue, Dec 18, 2007 at 05:59:11PM +1100, Lachlan McIlroy wrote: > > > Please pull from the for-linus branch: > > > git pull git

Re: [GIT PULL] XFS update for 2.6.24-rc6

On Tue, Dec 18, 2007 at 05:59:11PM +1100, Lachlan McIlroy wrote: > Please pull from the for-linus branch: > git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus Linus, please don't pull this yet. A problem has been found in the dirent fix, and we've just fixed another mknod related regres

Re: xfs mknod regression

On Tue, Dec 18, 2007 at 05:36:42PM +, Christoph Hellwig wrote: > > This was broken by my '[XFS] simplify xfs_create/mknod/symlink prototype', > which assigned the re-shuffled ondisk dev_t back to the rdev variable in > xfs_vn_mknod. Because of that i_rdev is set to the ondisk dev_t instead >

Re: Important regression with XFS update for 2.6.24-rc6

On Tue, Dec 18, 2007 at 03:30:31PM +0100, Damien Wyart wrote: > * David Chinner <[EMAIL PROTECTED]> [071218 13:24]: > > Ok. I haven't noticed anything wrong with directories up to about > > 250,000 files in the last few days. The ls -l I just did on > > a directory

Re: Do not reset xfsquota flags on quotaless ro mount

On Tue, Dec 18, 2007 at 03:04:03PM +0100, Jan Engelhardt wrote: > Hi, > > > In https://bugzilla.novell.com/show_bug.cgi?id=345338 it is claimed that > resetting the quota flags in the mounting sequence rw,ro,rw is a bug, but I You mounted without quotas in the middle step, thereby invalidating t

Re: xfs mknod regression

On Mon, Dec 17, 2007 at 08:48:40PM -0800, Bret Towe wrote: > I hit a bug in 2.6.24-rc looks to be in 2.6.23 also so not sure how > long it's been there > with an xfs filesystem pbuilder has an issue using device files it > makes for chroot > the mknod command looks to work fine the file is created

Re: Important regression with XFS update for 2.6.24-rc6

On Tue, Dec 18, 2007 at 12:28:04PM +0100, Damien Wyart wrote: > Hello, > > As a follow-up to > (LKML seems down right now so I am not linking to it), I have detected an > important problem with these two patches: after applying them by hand

Re: [0/4] DST: Distributed storage.

On Mon, Dec 17, 2007 at 06:03:38PM +0300, Evgeniy Polyakov wrote: > DST passed all FS tests in LTP with XFS (modulo MAX_LOCK_DEPTH too low bug: > [ 8398.605691] BUG: MAX_LOCK_DEPTH too low! > [ 8398.609641] turning off the locking correctness validator. Evgeniy, can you please start reporting thes

Re: Possible recursive locking detected with XFS

On Thu, Dec 13, 2007 at 06:29:16PM +0300, Vladislav Bolkhovitin wrote: > I've just got it while running "dbench 200" over a XFS mounted > partition. Kernel is 2.6.23. See the attachment. .. > Dec 13 16:30:45 tst kernel: [ 917.365836] > = > Dec 13 1

Re: [PATCH] REQ-flags to/from BIO-flags bugfix

On Wed, Dec 12, 2007 at 08:54:07AM -0700, Matthew Wilcox wrote: > On Wed, Dec 12, 2007 at 08:18:14AM -0700, Matthew Wilcox wrote: > > I don't know whether BIO_RW_BARRIER is __REQ_SOFTBARRIER or > > __REQ_HARDBARRIER, so I didn't include that in this patch. There also > > doesn't seem to be a __REQ

Re: Regression - 2.6.24-rc3 - umem nvram card driver oops

On Tue, Dec 04, 2007 at 11:14:12AM +1100, Neil Brown wrote: > On Tuesday December 4, [EMAIL PROTECTED] wrote: > > Neil, > > > > I just upgraded an ia64 (Altix, 16k page size) test box to 2.6.24-rc3 > > from 2.6.23 and I get it panicing on boot in the umem driver. > > Cool - someone is using umem!

Regression - 2.6.24-rc3 - umem nvram card driver oops

Neil, I just upgraded an ia64 (Altix, 16k page size) test box to 2.6.24-rc3 from 2.6.23 and I get it panicing on boot in the umem driver. [ 55.499300] v2.3 : Micro Memory(tm) PCI memory board block driver [ 55.519331] ACPI: Unable to derive IRQ for device 0006:00:01.0 [ 55.528294] ACPI: PCI

Re: BUG: XFS/firefox-bin (2.6.23.8)

On Sun, Dec 02, 2007 at 09:06:19AM -0800, Avuton Olrich wrote: > Adding xfs to CC > > On Dec 2, 2007 9:02 AM, Avuton Olrich <[EMAIL PROTECTED]> wrote: > > Hello, > > > > 2.6.23.8 just crashed here, it had been up 8 days and suspended to > > disk many times in those 8 days. The process that crashed

Re: [PATCH] xfs: revert to double-buffering readdir

On Fri, Nov 30, 2007 at 12:45:05AM +0100, Christian Kujau wrote: > On Sun, 25 Nov 2007, Christoph Hellwig wrote: > >This patch does exactly that and reverts xfs_file_readdir to what's > >basically the 2.6.23 version minus the uio and vnops junk. > > Thanks, works here too (without nordirplus as a

Re: Race between generic_forget_inode() and sync_sb_inodes()?

On Fri, Nov 30, 2007 at 09:07:06AM +1100, Neil Brown wrote: > > Hi David, > > On Friday November 30, [EMAIL PROTECTED] wrote: > > > > > > I came across this because I've been making changes to XFS to avoid the > > inode hash, and I've found that I need to remove the inode from the > > dirty lis

Race between generic_forget_inode() and sync_sb_inodes()?

If we are in the process of dropping an inode and it is hashed, generic_forget_inode() will mark it I_WILL_FREE and drop the inode_lock before calling write_inode_now(). However, at this point, the inode is still on the sb->s_dirty_list so sync_sb_inodes() could see it and try to write it back. i

Re: XFS related Oops (suspend/resume related)

On Tue, Nov 27, 2007 at 04:51:38PM +0100, Rafael J. Wysocki wrote: > On Monday, 26 of November 2007, Rafael J. Wysocki wrote: > > On Monday, 26 of November 2007, David Chinner wrote: > > > Now there's a message that I haven't seen in about 3 years. > > > &g

Re: freeze vs freezer

On Sat, Nov 24, 2007 at 12:47:21AM +0100, Rafael J. Wysocki wrote: > On Thursday, 22 of November 2007, Jeremy Fitzhardinge wrote: > > It seems that a process blocked in a write to an xfs filesystem due to > > xfs_freeze cannot be frozen by the freezer. > > The freezer doesn't handle tasks in TASK_

Re: XFS related Oops (suspend/resume related)

On Mon, Nov 26, 2007 at 02:12:10PM +0100, Tino Keitel wrote: > On Wed, Nov 14, 2007 at 10:04:45 +1100, David Chinner wrote: > > On Tue, Nov 13, 2007 at 11:51:19AM +0100, Tino Keitel wrote: > > > On Tue, Nov 13, 2007 at 09:27:20 +1100, David Chinner wrote: > > > > &g

Re: [PATCH 1/9]: introduce radix_tree_gang_lookup_range

On Mon, Nov 26, 2007 at 10:17:24AM +1100, Nick Piggin wrote: > On Thursday 22 November 2007 11:32, David Chinner wrote: > > Introduce radix_tree_gang_lookup_range() > > > > The inode clustering in XFS requires a gang lookup on the radix tree to > > find all the inode

Re: [PATCH 2/9]: Reduce Log I/O latency

On Fri, Nov 23, 2007 at 03:53:17AM +0100, Andi Kleen wrote: > On Fri, Nov 23, 2007 at 12:15:39AM +1100, David Chinner wrote: > > On Thu, Nov 22, 2007 at 01:06:11PM +0100, Andi Kleen wrote: > > > > FWIW from a "real time" database POV this seems to make sense to me.

Re: [PATCH 2/9]: Reduce Log I/O latency

On Fri, Nov 23, 2007 at 09:29:09AM +1100, David Chinner wrote: > On Thu, Nov 22, 2007 at 12:10:29PM -0600, Matt Mackall wrote: > > If I've got XFS on filesystems A and B on the same spindle (or volume > > group?) and my real RT I/O takes place only on B, then I want log >

Re: [PATCH 2/9]: Reduce Log I/O latency

On Thu, Nov 22, 2007 at 12:10:29PM -0600, Matt Mackall wrote: > On Thu, Nov 22, 2007 at 09:31:59PM +1100, David Chinner wrote: > [...] > > > In other words, I/O priority is per-spindle and not per-filesystem and > > > thus this change has consequences that leak o

Re: [PATCH 2/9]: Reduce Log I/O latency

On Thu, Nov 22, 2007 at 01:06:11PM +0100, Andi Kleen wrote: > > FWIW from a "real time" database POV this seems to make sense to me... > > in fact, we probably rely on filesystem metadata way too much > > (historically it's just "worked" although we do seem to get issues > > on ext3). > > For

Re: [PATCH 2/9]: Reduce Log I/O latency

On Thu, Nov 22, 2007 at 01:25:49AM -0600, Matt Mackall wrote: > On Thu, Nov 22, 2007 at 02:41:06PM +1100, David Chinner wrote: > > On Wed, Nov 21, 2007 at 08:57:27PM -0600, Matt Mackall wrote: > > > On Thu, Nov 22, 2007 at 12:12:14PM +1100, David Chinner wrote: > > > >

Re: [PATCH 2/9]: Reduce Log I/O latency

On Wed, Nov 21, 2007 at 08:57:27PM -0600, Matt Mackall wrote: > On Thu, Nov 22, 2007 at 12:12:14PM +1100, David Chinner wrote: > > In all the cases that I know of where ppl are using what could > > be considered real-time I/O (e.g. media environments where they > > do real-ti

Re: [PATCH 2/9]: Reduce Log I/O latency

On Thu, Nov 22, 2007 at 01:49:25AM +0100, Andi Kleen wrote: > David Chinner <[EMAIL PROTECTED]> writes: > > > To ensure that log I/O is issued as the highest priority I/O, set > > the I/O priority of the log I/O to the highest possible. This will > > ensure that log

[PATCH 9/9] Clean up open coded inode dirty checks

Use xfs_inode_clean() in more places. Signed-off-by: Dave Chinner <[EMAIL PROTECTED]> --- fs/xfs/xfs_inode.c | 27 +-- fs/xfs/xfs_inode_item.h |8 fs/xfs/xfs_vnodeops.c |4 +--- 3 files changed, 14 insertions(+), 25 deletions(-) Index: 2.6.x-xfs-

[PATCH 8/9] Convert inode cache locking to RCU

Use RCU locking on the inode radix trees To make use of the efficient radix tree gang lookups for inode cluster operations we had to increase the time we hold the radix tree read lock for. This will affect performance somewhat. Given that all the lookups are done on a radix tree and we already ha

[PATCH 7/9] Use radix_tree_gang_lookup_range for cluster lookups

Use radix_tree_gang_lookup_range() for inode cluster lookups Now that we have an efficent lookup method for the radix tree, convert cluster lookups to use it. Factor out the common lookup, add some debug checking to it and call it where needed. For sanity, we need to hold the radix tree lock in r

[PATCH 6/9] Remove xfs_icluster

Remove the xfs_icluster structure and replace with a radix tree lookup. We don't need to keep a list of inodes in each cluster around anymore as we can look them up quickly when we need to. The only time we need to do this now is during inode writeback. Factor the inode cluster writeback code out

[PATCH 5/9] Don't block pdflush when flushing inodes

When pdflush is writing back inodes, it can get stuck on inode cluster buffers that are currently under I/O. This occurs when we write data to multiple inodes in the same inode cluster at the same time. Effectively, delayed allocation marks the inode dirty during the data writeback. Hence if the i

[PATCH 3/9] Use _META bio I/O types for metadata I/O

Improve metadata I/O merging in the elevator Change all async metadata buffers to use [READ|WRITE]_META I/O types so that the I/O doesn't get issued immediately. This allows merging of adjacent metadata requests but still prioritises them over bulk data. This shows a 10-15% improvement in sequenti

[PATCH 4/9] Factor common inode cluster buffer lookup code

Factor xfs_itobp() and xfs_inotobp(). The only difference between the functions is one passes an inode for the lookup, the other passes an inode number. However, they don't do the same validity checking or set all the same state on the buffer that is returned yet they should. Factor the functions

[PATCH 2/9]: Reduce Log I/O latency

Reduce log I/O latency To ensure that log I/O is issued as the highest priority I/O, set the I/O priority of the log I/O to the highest possible. This will ensure that log I/O is not held up behind bulk data or other metadata I/O as delaying log I/O can pause the entire transaction subsystem. Intr

[PATCH 1/9]: introduce radix_tree_gang_lookup_range

Introduce radix_tree_gang_lookup_range() The inode clustering in XFS requires a gang lookup on the radix tree to find all the inodes in the cluster. The gang lookup has to set the maximum items to that of a fully populated cluster so we get all the inodes in the cluster, but we only populate the

[PATCH 0/9]: Various XFS inode clustering improvements

Normally I wouldn't bother cc'ing lkml on XFS changes, however a couple of these patches touch generic code. The changes to generic code are introducing a WRITE_META bio type and radix_tree_gang_lookup_range() and hence the wider ditribution. This patch set is against the current xfs-dev tree so b

Re: [rfc 18/45] cpu alloc: XFS counters

On Tue, Nov 20, 2007 at 12:38:29PM -0800, Christoph Lameter wrote: > On Tue, 20 Nov 2007, Christoph Hellwig wrote: > > > On Mon, Nov 19, 2007 at 05:11:50PM -0800, [EMAIL PROTECTED] wrote: > > > Also remove the useless zeroing after allocation. Allocpercpu already > > > zeroed the objects. > > > >

Re: writeout stalls in current -git

or each inode in the cluster we > > > > have to write. > > > > Works for me. The only remaining stalls are sub second and look > > > completely valid, considering the amount of files being removed. > > > > > Tested-by: Torsten Kaiser <[EMAIL

Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

On Sun, Nov 18, 2007 at 01:33:50PM +0100, Peter Zijlstra wrote: > > On Sat, 2007-11-17 at 10:12 -0800, Daniel Walker wrote: > > > What specifically is wrong with dev->sem ? > > Nothing really, other than that they use semaphores to avoid lockdep :-/ > > I think I know how to annotate this, afte

Re: XFS related Oops

On Tue, Nov 13, 2007 at 11:51:19AM +0100, Tino Keitel wrote: > On Tue, Nov 13, 2007 at 09:27:20 +1100, David Chinner wrote: > > [...] > > > No. I'd say something got screwed up during suspend/resume. Is it > > reproducable? > > No. I often use suspend to RAM

Re: XFS related Oops

On Mon, Nov 12, 2007 at 07:47:06AM +0100, Tino Keitel wrote: > Hi, > > after resume from suspend with 2.6.23.1, I got the following Oops: > > BUG: unable to handle kernel paging request at virtual address 3e0d204c > printing eip: > c022807f > *pde = > Oops: [#1] > SMP > Modules li

Re: writeout stalls in current -git

On Wed, Nov 07, 2007 at 08:15:06AM +0100, Torsten Kaiser wrote: > On 11/7/07, David Chinner <[EMAIL PROTECTED]> wrote: > > Ok, so it's not synchronous writes that we are doing - we're just > > submitting bio's tagged as WRITE_SYNC to get the I/O issued quickly.

Re: writeout stalls in current -git

On Wed, Nov 07, 2007 at 10:31:14AM +1100, David Chinner wrote: > On Tue, Nov 06, 2007 at 10:53:25PM +0100, Torsten Kaiser wrote: > > On 11/6/07, David Chinner <[EMAIL PROTECTED]> wrote: > > > Rather than vmstat, can you use something like iostat to show how busy > >

Re: writeout stalls in current -git

On Tue, Nov 06, 2007 at 10:53:25PM +0100, Torsten Kaiser wrote: > On 11/6/07, David Chinner <[EMAIL PROTECTED]> wrote: > > Rather than vmstat, can you use something like iostat to show how busy your > > disks are? i.e. are we seeing RMW cycles in the raid5 or some such issue.

Re: writeout stalls in current -git

On Mon, Nov 05, 2007 at 07:27:16PM +0100, Torsten Kaiser wrote: > On 11/5/07, David Chinner <[EMAIL PROTECTED]> wrote: > > Ok, so it's probably a side effect of the writeback changes. > > > > Attached are two patches (two because one was in a separate patchset

Re: writeout stalls in current -git

On Sun, Nov 04, 2007 at 12:19:19PM +0100, Torsten Kaiser wrote: > On 11/2/07, David Chinner <[EMAIL PROTECTED]> wrote: > > That's stalled waiting on the inode cluster buffer lock. That implies > > that the inode lcuser is already being written out and the inode has

Re: writeout stalls in current -git

On Fri, Nov 02, 2007 at 08:22:10PM +0100, Torsten Kaiser wrote: > [ 630.00] SysRq : Emergency Sync > [ 630.12] Emergency Sync complete > [ 632.85] SysRq : Show Blocked State > [ 632.85] taskPC stack pid father > [ 632.85] pdflush D 8100

Re: [PATCH] VFS: new fgetattr() file operation

On Fri, Oct 26, 2007 at 01:10:14AM +0200, Miklos Szeredi wrote: > > On Wed, Oct 24, 2007 at 05:27:04PM +0200, Miklos Szeredi wrote: > > > > >> Wouldn't you be better off by attempting to implement an "open > > > > >> by ino" operation and an operation to get the generation count > > > > >> for the

Re: [PATCH] VFS: new fgetattr() file operation

On Wed, Oct 24, 2007 at 05:27:04PM +0200, Miklos Szeredi wrote: > > >> Wouldn't you be better off by attempting to implement an "open > > >> by ino" operation and an operation to get the generation count > > >> for the file and then modifying the network protocol of interest > > >> to use these as

  1   2   3   4   5   >