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't see
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't see anything that cold pin them (e.g
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 be
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,
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.
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.
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, please.
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 behaviour. The machine
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
> > barrier I/
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
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
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,
&
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,
xfsaild is causing many wakeups, a quick investigation shows
xfsaild_push
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 noticed
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 latter
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
barrier I/O from the filesystem
My
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
> >
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
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 power
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
attempt to
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
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
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
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 master
Added, thanks.
I have put you
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 multi-gi
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,
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,
no
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 multi-gig files
going on at same time, both
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
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
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 submitters to
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 can add a:
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?
> >
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.
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
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 prevent the lockup,
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.
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?
http://oss.sgi.com/archives/xfs/2008-02
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
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,
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
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,
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
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
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, in this
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 idea that allowing the submitting application control
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
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)
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
> 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,
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 and XFS I
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 (thaw_bdev) in ext3_ioctl
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)
is
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 convert XFS to use
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
> > >
> > >
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(>m_active_trans) == 0, file:
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
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,
> >
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,
not just for readahead, because fsck
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
well.
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:
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_oops/
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.
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. The
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
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 dependency
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
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
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 looking at is
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
>
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
>
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
multiple
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
based on
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:
> > > >
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
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
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
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 that data
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:
Then to do better ordering
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
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
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 the few disks
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 quick
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
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 near
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
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-global
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
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 c
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
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
> > > 2
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
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
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
250,000 files in the last few days. The ls -l I
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 haven't seen it - it requires the user
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 I've been working on uses a -copy_keys() method for
copying the keys
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 called under the read_lock
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]
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
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
1 - 100 of 837 matches
Mail list logo
