r this patch so I just wanted to
say thanks and since I've used it a fair bit feel free to add:
Tested-by: Nathan Scott
One small tweak you could make is to drop the extra whitespace
from those new seq_printf calls - "\t%d " has a trailing space
that isn't needed.
Also the
picking
this up.
I recently came across a need for this patch so I just wanted to
say thanks and since I've used it a fair bit feel free to add:
Tested-by: Nathan Scott nath...@redhat.com
One small tweak you could make is to drop the extra whitespace
from those new seq_printf calls - \t%d has
On Tue, 2007-09-18 at 18:06 -0700, Linus Torvalds wrote:
> There is *no* valid reason for 16kB blocksizes unless you have legacy
> issues.
That's not correct.
> The performance issues have nothing to do with the block-size, and
We must be thinking of different performance issues.
> should be
On Tue, 2007-09-18 at 12:44 -0700, Linus Torvalds wrote:
> This is not about performance. Never has been. It's about SGI wanting a
> way out of their current 16kB mess.
Pass the crack pipe, Linus?
> The way to fix performance is to move to x86-64, and use 4kB pages and be
> happy. However, the
On Tue, 2007-09-18 at 12:44 -0700, Linus Torvalds wrote:
This is not about performance. Never has been. It's about SGI wanting a
way out of their current 16kB mess.
Pass the crack pipe, Linus?
The way to fix performance is to move to x86-64, and use 4kB pages and be
happy. However, the SGI
On Tue, 2007-09-18 at 18:06 -0700, Linus Torvalds wrote:
There is *no* valid reason for 16kB blocksizes unless you have legacy
issues.
That's not correct.
The performance issues have nothing to do with the block-size, and
We must be thinking of different performance issues.
should be
On Thu, 2007-06-28 at 23:49 +0530, Amit K. Arora wrote:
>
> > Correct, but for swap files that's not an issue - no user should be
> able
> > too read them, and FA_MKSWAP would really need root privileges to
> execute.
>
> Will the FA_MKSWAP mode still be required with your suggested change
> of
On Thu, 2007-06-28 at 23:49 +0530, Amit K. Arora wrote:
Correct, but for swap files that's not an issue - no user should be
able
too read them, and FA_MKSWAP would really need root privileges to
execute.
Will the FA_MKSWAP mode still be required with your suggested change
of
teaching
On Tue, 2007-05-22 at 20:44 +1000, David Chinner wrote:
>
> > xfs_buf_associate_memory is a mess. My original plan was to get rid
> of
> > it, but I kept that out to keep that patchset small and easily
> reviable,
> > but it seems like that was a mistake. My plan is the following:
> >
> > -
On Tue, 2007-05-22 at 20:44 +1000, David Chinner wrote:
xfs_buf_associate_memory is a mess. My original plan was to get rid
of
it, but I kept that out to keep that patchset small and easily
reviable,
but it seems like that was a mistake. My plan is the following:
- xlog_bread and
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
> On Fri, 2 Mar 2007 00:04:45 +0530
> "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
>
> > This is to give a heads up on few patches that we will be soon coming up
> > with. These patches implement a new system call sys_fallocate() and a
> > new
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
Amit K. Arora [EMAIL PROTECTED] wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode
On Tue, 2007-01-09 at 15:49 +1100, David Chinner wrote:
> On Tue, Jan 09, 2007 at 03:17:03PM +1100, Nathan Scott wrote:
> > On Mon, 2007-01-08 at 19:51 -0800, Andrew Morton wrote:
> > > If that's not true, then what _is_ happening in there?
> >
> > This particular
On Mon, 2007-01-08 at 19:51 -0800, Andrew Morton wrote:
> On Mon, 08 Jan 2007 21:38:05 -0600
> Eric Sandeen <[EMAIL PROTECTED]> wrote:
>
> > Andrew Morton wrote:
> > > On Mon, 08 Jan 2007 21:12:40 -0600
> > > Eric Sandeen <[EMAIL PROTECTED]> wrote:
> > >
> > >> Andrew Morton wrote:
> > >>> On
On Mon, 2007-01-08 at 22:54 +, Christoph Hellwig wrote:
> this doesn't look like a full first class flag to me yet. Don't
> we need to check for buffer_unwritten in the places we're checking
> for buffer_delay so we can stop setting buffer_delay for unwritten
> buffers?
Yep, that does need
On Mon, 2007-01-08 at 22:54 +, Christoph Hellwig wrote:
this doesn't look like a full first class flag to me yet. Don't
we need to check for buffer_unwritten in the places we're checking
for buffer_delay so we can stop setting buffer_delay for unwritten
buffers?
Yep, that does need to be
On Mon, 2007-01-08 at 19:51 -0800, Andrew Morton wrote:
On Mon, 08 Jan 2007 21:38:05 -0600
Eric Sandeen [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Mon, 08 Jan 2007 21:12:40 -0600
Eric Sandeen [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Tue, 9 Jan 2007 10:47:28
On Tue, 2007-01-09 at 15:49 +1100, David Chinner wrote:
On Tue, Jan 09, 2007 at 03:17:03PM +1100, Nathan Scott wrote:
On Mon, 2007-01-08 at 19:51 -0800, Andrew Morton wrote:
If that's not true, then what _is_ happening in there?
This particular case was a device mapper stack trace
On Thu, Sep 08, 2005 at 07:12:01PM -0600, Alejandro Bonilla Beeche wrote:
> Hi,
> ld: fs/xfs/quota/: No such file: File format not recognized
> make[3]: *** [fs/xfs/xfs.o] Error 1
> make[2]: *** [fs/xfs] Error 2
> make[1]: *** [fs] Error 2
> make[1]: Leaving directory `/root/linux-2.6'
> make: ***
On Thu, Sep 08, 2005 at 07:12:01PM -0600, Alejandro Bonilla Beeche wrote:
Hi,
ld: fs/xfs/quota/: No such file: File format not recognized
make[3]: *** [fs/xfs/xfs.o] Error 1
make[2]: *** [fs/xfs] Error 2
make[1]: *** [fs] Error 2
make[1]: Leaving directory `/root/linux-2.6'
make: ***
Hi Tony,
On Wed, Sep 07, 2005 at 02:45:49PM -0700, Luck, Tony wrote:
> I see a lot (90) of warnings when building xfs on ia64. The
Christoph has a patch pending (slightly different approach to
yours) that should resolve this.
cheers.
--
Nathan
-
To unsubscribe from this list: send the line
Hi Tony,
On Wed, Sep 07, 2005 at 02:45:49PM -0700, Luck, Tony wrote:
I see a lot (90) of warnings when building xfs on ia64. The
Christoph has a patch pending (slightly different approach to
yours) that should resolve this.
cheers.
--
Nathan
-
To unsubscribe from this list: send the line
On Thu, Sep 01, 2005 at 10:33:56PM -0700, Chris Wedgwood wrote:
> On Fri, Sep 02, 2005 at 02:39:15AM +0200, Adrian Bunk wrote:
>
> > 4Kb kernel stacks are the future on i386, and it seems the problems
> > it initially caused are now sorted out.
>
> Not entirely.
>
> XFS when mixed with
On Thu, Sep 01, 2005 at 10:33:56PM -0700, Chris Wedgwood wrote:
On Fri, Sep 02, 2005 at 02:39:15AM +0200, Adrian Bunk wrote:
4Kb kernel stacks are the future on i386, and it seems the problems
it initially caused are now sorted out.
Not entirely.
XFS when mixed with raid/lvm/nfs still
On Wed, Aug 31, 2005 at 02:33:10PM +1000, Nathan Scott wrote:
> ...
> On an unrelated note, are there any known issues with using epoll
> on relayfs file descriptors? I'm having a few troubles, and just
> wondering if its me doing something silly, or if its known to not
> wor
Hi Tom,
On Tue, Aug 30, 2005 at 11:19:04PM -0500, Tom Zanussi wrote:
> You're right, it should be using simple_rmdir rather than
> simple_unlink for removing directories. Thanks for sending the patch,
No problem.
> which I've modified a bit to avoid splitting the rmdir/unlink cases
> into
Hi there,
On Wed, Aug 31, 2005 at 09:48:23AM +1000, Nathan Scott wrote:
> ...
> # find /relay
> /relay
> /relay/block
> /relay/block/sdd
> /relay/block/sdd/trace3
> /relay/block/sdd/trace2
> /relay/block/sdd/trace1
> /relay/block/sdd/trace0
> /relay/block/sdb
>
Hi Jens,
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> Ok, updated version.
One thing I found a bit awkward was the way its putting all inodes
in the root of the relayfs namespace, with the cpuid tacked on the
end of the bdevname - I was a bit confused at first when a trace of
Hi Jens,
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
> relayfs read update from the previous mail [*] as well.
There's a small memory leak there on one of the start-tracing
error paths (relay_open
Hi Jens,
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
relayfs read update from the previous mail [*] as well.
There's a small memory leak there on one of the start-tracing
error paths (relay_open
Hi Jens,
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
Ok, updated version.
One thing I found a bit awkward was the way its putting all inodes
in the root of the relayfs namespace, with the cpuid tacked on the
end of the bdevname - I was a bit confused at first when a trace of
sdd
Hi there,
On Wed, Aug 31, 2005 at 09:48:23AM +1000, Nathan Scott wrote:
...
# find /relay
/relay
/relay/block
/relay/block/sdd
/relay/block/sdd/trace3
/relay/block/sdd/trace2
/relay/block/sdd/trace1
/relay/block/sdd/trace0
/relay/block/sdb
/relay/block/sdb/trace3
/relay/block/sdb
Hi Tom,
On Tue, Aug 30, 2005 at 11:19:04PM -0500, Tom Zanussi wrote:
You're right, it should be using simple_rmdir rather than
simple_unlink for removing directories. Thanks for sending the patch,
No problem.
which I've modified a bit to avoid splitting the rmdir/unlink cases
into separate
On Wed, Aug 31, 2005 at 02:33:10PM +1000, Nathan Scott wrote:
...
On an unrelated note, are there any known issues with using epoll
on relayfs file descriptors? I'm having a few troubles, and just
wondering if its me doing something silly, or if its known to not
work...? Symptoms
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> ...
> Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
> relayfs read update from the previous mail [*] as well.
Hi Jens,
There's a minor config botch in there, I get this:
scripts/kconfig/conf -s
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
...
Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
relayfs read update from the previous mail [*] as well.
Hi Jens,
There's a minor config botch in there, I get this:
scripts/kconfig/conf -s
On Wed, Aug 24, 2005 at 09:08:10AM +0200, Jens Axboe wrote:
> ...
> This isn't msec precision, it's usec. sched_clock() is in ns! I already
> decided that msec is too coarse, but usec _should_ be enough.
Right you are (I was thinking m-for-micro, not m-for-milli in my head ;)
- but still, there
Hi Jens,
On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
> ...
> + t.pid = current->pid;
> ...
> +/*
> + * The trace itself
> + */
> +struct blk_io_trace {
> + u32 magic; /* MAGIC << 8 | version */
> + u32 sequence; /* event number */
> +
Hi Jens,
On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
...
+ t.pid = current-pid;
...
+/*
+ * The trace itself
+ */
+struct blk_io_trace {
+ u32 magic; /* MAGIC 8 | version */
+ u32 sequence; /* event number */
+ u64 time;
On Wed, Aug 24, 2005 at 09:08:10AM +0200, Jens Axboe wrote:
...
This isn't msec precision, it's usec. sched_clock() is in ns! I already
decided that msec is too coarse, but usec _should_ be enough.
Right you are (I was thinking m-for-micro, not m-for-milli in my head ;)
- but still, there
On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
> Hi,
>
> This is a little something I have played with. It allows you to see
> exactly what is going on in the block layer for a given queue. Currently
> it can logs request queueing and building, dispatches, requeues, and
>
> On 8/19/05, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> > According to the SuS write() can not return ENOMEM, only ENOBUFS is allowed
> > (surprisingly read() is allowed to use both ENOMEM and ENOBUFS):
> >
> > http://www.opengroup.org/onlinepubs/95399/functions/write.html
> >
> > Should
On 8/19/05, Dmitry Torokhov [EMAIL PROTECTED] wrote:
According to the SuS write() can not return ENOMEM, only ENOBUFS is allowed
(surprisingly read() is allowed to use both ENOMEM and ENOBUFS):
http://www.opengroup.org/onlinepubs/95399/functions/write.html
Should we adjust sysfs
On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
Hi,
This is a little something I have played with. It allows you to see
exactly what is going on in the block layer for a given queue. Currently
it can logs request queueing and building, dispatches, requeues, and
completions.
Ah,
On Thu, Aug 18, 2005 at 11:09:33PM +0200, Jesper Juhl wrote:
> ...
> have if getting rid of the defines is prefered, then that's something that
> can easily be done later.
I tend to agree with Christoph on this - this level of internal API
churn is unnecessary and can be error prone (as you
On Thu, Aug 18, 2005 at 06:49:05PM +, kristina clair wrote:
> I've just come across this oops. We're running gentoo with a 2.6.11
> kernel, xfs + nfs + lvm (+hardware raid).
Check whether your kernel has this fix included:
On Thu, Aug 18, 2005 at 10:22:26AM -0500, Russell Cattelan wrote:
> .. fs/xfs/Kconfig but using submenu was simply a convince thing
> to group all the XFS options together.
s/convince/convenience/
> If the submenu is really causing people distress go ahead and
> remove it. Since it's a
On Thu, Aug 18, 2005 at 10:22:26AM -0500, Russell Cattelan wrote:
.. fs/xfs/Kconfig but using submenu was simply a convince thing
to group all the XFS options together.
s/convince/convenience/
If the submenu is really causing people distress go ahead and
remove it. Since it's a cosmetic
On Thu, Aug 18, 2005 at 06:49:05PM +, kristina clair wrote:
I've just come across this oops. We're running gentoo with a 2.6.11
kernel, xfs + nfs + lvm (+hardware raid).
Check whether your kernel has this fix included:
On Thu, Aug 18, 2005 at 11:09:33PM +0200, Jesper Juhl wrote:
...
have if getting rid of the defines is prefered, then that's something that
can easily be done later.
I tend to agree with Christoph on this - this level of internal API
churn is unnecessary and can be error prone (as you
On Thu, Jul 28, 2005 at 05:03:02PM -0700, Mark Bellon wrote:
> The attached patchs modify the EXT[2|3] and [X|J]FS codes to add the
The XFS component is incorrect, we're already doing this elsewhere
(over in fs/xfs/quota/xfs_qm_bhv.c), so please drop this last part
from your patch...
> diff
On Thu, Jul 28, 2005 at 05:03:02PM -0700, Mark Bellon wrote:
The attached patchs modify the EXT[2|3] and [X|J]FS codes to add the
The XFS component is incorrect, we're already doing this elsewhere
(over in fs/xfs/quota/xfs_qm_bhv.c), so please drop this last part
from your patch...
diff -Naur
On Wed, Jul 13, 2005 at 06:22:28PM +0300, Yura Pakhuchiy wrote:
> I found patch by Greg Ungreger to fix this problem, but why it's still
> not in mainline? Or it's a gcc problem and should be fixed by gcc folks?
Yes, IIRC the patch was incorrect for other platforms, and it sure
looked like an
Hi there,
On Wed, Jul 13, 2005 at 09:45:58AM -0700, Daniel Walker wrote:
> On Wed, 2005-07-13 at 08:47 +0200, Ingo Molnar wrote:
> >
> > downgrade_write() wasnt the main problem - the main problem was that for
> > PREEMPT_RT i implemented 'strict' semaphores, which are not identical to
> >
Hi there,
On Wed, Jul 13, 2005 at 09:45:58AM -0700, Daniel Walker wrote:
On Wed, 2005-07-13 at 08:47 +0200, Ingo Molnar wrote:
downgrade_write() wasnt the main problem - the main problem was that for
PREEMPT_RT i implemented 'strict' semaphores, which are not identical to
vanilla
On Wed, Jul 13, 2005 at 06:22:28PM +0300, Yura Pakhuchiy wrote:
I found patch by Greg Ungreger to fix this problem, but why it's still
not in mainline? Or it's a gcc problem and should be fixed by gcc folks?
Yes, IIRC the patch was incorrect for other platforms, and it sure
looked like an
On Tue, Jul 12, 2005 at 05:41:43PM -0700, Daniel Walker wrote:
> On Wed, 2005-07-13 at 10:25 +1000, Nathan Scott wrote:
> > On Tue, Jul 12, 2005 at 04:01:32PM -0700, Daniel Walker wrote:
> > >
> > > Is there something so odd about the XFS locking, that it
On Tue, Jul 12, 2005 at 04:01:32PM -0700, Daniel Walker wrote:
>
> Is there something so odd about the XFS locking, that it can't use the
> rt_lock ?
Not that I know of - XFS does use the downgrade_write interface,
whose use isn't overly common in the rest of the kernel... maybe
that has caused
On Tue, Jul 12, 2005 at 04:01:32PM -0700, Daniel Walker wrote:
Is there something so odd about the XFS locking, that it can't use the
rt_lock ?
Not that I know of - XFS does use the downgrade_write interface,
whose use isn't overly common in the rest of the kernel... maybe
that has caused
On Tue, Jul 12, 2005 at 05:41:43PM -0700, Daniel Walker wrote:
On Wed, 2005-07-13 at 10:25 +1000, Nathan Scott wrote:
On Tue, Jul 12, 2005 at 04:01:32PM -0700, Daniel Walker wrote:
Is there something so odd about the XFS locking, that it can't use the
rt_lock ?
Not that I know
Hi there,
On Sat, Jul 09, 2005 at 06:20:53AM -0400, Justin Piszcz wrote:
> After a couple hours of use, I get this error on a linear RAID under
> 2.6.12.2 using loop-AES w/AES-256 encrypted filesystem.
>
> Anyone know what is wrong?
This is not an Oops as your subject line states ... its a
Hi there,
On Sat, Jul 09, 2005 at 06:20:53AM -0400, Justin Piszcz wrote:
After a couple hours of use, I get this error on a linear RAID under
2.6.12.2 using loop-AES w/AES-256 encrypted filesystem.
Anyone know what is wrong?
This is not an Oops as your subject line states ... its a forced
On Thu, Jul 07, 2005 at 08:15:52PM +0300, Yura Pakhuchiy wrote:
> Hi,
>
> I'm creadted XFS volume on 2.6.10 linux xscale/iq31244 box, then I
> copyied files on it and moved this hard drive to i686 machine. When I
> mounted it on i686, I found no files on it. I runned xfs_check, here is
> output:
On Thu, Jul 07, 2005 at 08:15:52PM +0300, Yura Pakhuchiy wrote:
Hi,
I'm creadted XFS volume on 2.6.10 linux xscale/iq31244 box, then I
copyied files on it and moved this hard drive to i686 machine. When I
mounted it on i686, I found no files on it. I runned xfs_check, here is
output:
Hi Nicholas,
On Sat, Jul 02, 2005 at 10:41:08PM +0100, Nicholas Hans Simmonds wrote:
> This is a simple attempt at providing capability support through extended
> attributes.
> ...
> +#define XATTR_CAP_SET XATTR_SECURITY_PREFIX "cap_set"
> ...
> + ret =
On Wed, Jul 06, 2005 at 07:24:03AM +0300, Al Boldi wrote:
> Was ordered mode disabled/removed when XFS was add to the vanilla-kernel?
No, XFS has never supported such a mode.
cheers.
--
Nathan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Wed, Jul 06, 2005 at 07:24:03AM +0300, Al Boldi wrote:
Was ordered mode disabled/removed when XFS was add to the vanilla-kernel?
No, XFS has never supported such a mode.
cheers.
--
Nathan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Hi Nicholas,
On Sat, Jul 02, 2005 at 10:41:08PM +0100, Nicholas Hans Simmonds wrote:
This is a simple attempt at providing capability support through extended
attributes.
...
+#define XATTR_CAP_SET XATTR_SECURITY_PREFIX cap_set
...
+ ret =
On Tue, Jul 05, 2005 at 11:08:15AM -0500, Andy wrote:
> I'd like to do an online resize of and XFS filesystem on a non-partitioned
> device. But, I always have to reboot to do so.
>
> Say I have a sdc with 16777216 blocks and expand it on the SAN
> to have 17825792 blocks, and rescan the device.
On Tue, Jul 05, 2005 at 11:08:15AM -0500, Andy wrote:
I'd like to do an online resize of and XFS filesystem on a non-partitioned
device. But, I always have to reboot to do so.
Say I have a sdc with 16777216 blocks and expand it on the SAN
to have 17825792 blocks, and rescan the device.
On Tue, Apr 12, 2005 at 01:51:10AM +0200, Pavel Machek wrote:
> I should take some sleep now, so I can't test the patch, but I don't
> think it will help. If someone has PF_FREEZE set, he should be in
> refrigerator.
OK, so if that doesn't help, here's an alternate approach - this
lets xfsbufd
On Mon, Apr 11, 2005 at 12:57:59PM +0200, Pavel Machek wrote:
> Hi!
>
> > > > No, XFS is my root filesystem. :( (Now that I think about it, would
> > > > modularizing XFS and using an initrd be OK?)
> > >
> > > Yes, loading xfs from initrd should help. [At least it did during
> > > suse9.3
On Mon, Apr 11, 2005 at 12:57:59PM +0200, Pavel Machek wrote:
Hi!
No, XFS is my root filesystem. :( (Now that I think about it, would
modularizing XFS and using an initrd be OK?)
Yes, loading xfs from initrd should help. [At least it did during
suse9.3 testing.]
Once I
On Tue, Apr 12, 2005 at 01:51:10AM +0200, Pavel Machek wrote:
I should take some sleep now, so I can't test the patch, but I don't
think it will help. If someone has PF_FREEZE set, he should be in
refrigerator.
OK, so if that doesn't help, here's an alternate approach - this
lets xfsbufd track
On Thu, Mar 31, 2005 at 10:42:58AM +1000, Nathan Scott wrote:
> On Wed, Mar 30, 2005 at 01:06:01PM -0700, Andreas Dilger wrote:
> > The correct fix, used for reiserfs (and a patch for ext3 also) is to
> > set i_nlink = 1 in case the filesystem count has wrapped. When nlink==1
&
On Wed, Mar 30, 2005 at 01:06:01PM -0700, Andreas Dilger wrote:
> On Mar 30, 2005 20:43 +0100, David Malone wrote:
> > It seems that internally xfs uses a 32 bit field for the link count,
> > and the stat64 syscalls use a 32 bit field. These fields are copied
> > via the vattr structure in
On Wed, Mar 30, 2005 at 01:06:01PM -0700, Andreas Dilger wrote:
On Mar 30, 2005 20:43 +0100, David Malone wrote:
It seems that internally xfs uses a 32 bit field for the link count,
and the stat64 syscalls use a 32 bit field. These fields are copied
via the vattr structure in xfs_vnode.h,
On Thu, Mar 31, 2005 at 10:42:58AM +1000, Nathan Scott wrote:
On Wed, Mar 30, 2005 at 01:06:01PM -0700, Andreas Dilger wrote:
The correct fix, used for reiserfs (and a patch for ext3 also) is to
set i_nlink = 1 in case the filesystem count has wrapped. When nlink==1
the fts/find code
On Mon, Mar 28, 2005 at 02:44:30PM -0800, Chris Wright wrote:
> * Ali Akcaagac ([EMAIL PROTECTED]) wrote:
> > And happy easter to you all. Just got this while trying to delete some
> > files on my system.
> ...
> > : EIP is at linvfs_open+0x59/0xa0
> ...
> Nothing in the -stable series has changed
On Mon, Mar 28, 2005 at 02:44:30PM -0800, Chris Wright wrote:
* Ali Akcaagac ([EMAIL PROTECTED]) wrote:
And happy easter to you all. Just got this while trying to delete some
files on my system.
...
: EIP is at linvfs_open+0x59/0xa0
...
Nothing in the -stable series has changed either
On Sat, Mar 12, 2005 at 02:14:50AM -0800, Junfeng Yang wrote:
>
> Hi,
>
> We are from the Stanford Checker team and are working on a file system
> checker called FiSC. We checked XFS and found that even when a XFS
> partition is mounted -o sync, file system operations are still not sync'ed
>
On Sat, Mar 12, 2005 at 02:14:50AM -0800, Junfeng Yang wrote:
Hi,
We are from the Stanford Checker team and are working on a file system
checker called FiSC. We checked XFS and found that even when a XFS
partition is mounted -o sync, file system operations are still not sync'ed
On Thu, Mar 10, 2005 at 09:10:42PM -0800, Roland Dreier wrote:
> Andrew> (Why do they want to do this anyway?)
>
> Neither use seems really fundamental. The XFS use is explicitly
> inside #ifdef DEBUG and seems to be used only for assertions.
Right, our peeking at that value is debug-only
On Thu, Mar 10, 2005 at 09:10:42PM -0800, Roland Dreier wrote:
Andrew (Why do they want to do this anyway?)
Neither use seems really fundamental. The XFS use is explicitly
inside #ifdef DEBUG and seems to be used only for assertions.
Right, our peeking at that value is debug-only (so
On Sun, Feb 27, 2005 at 01:34:31PM -0600, Stephen Lord wrote:
> Torben Viets wrote:
> >
> > I have a RAID 5(md0) with 3 disks on md0 (chunk-size 128) there is a
> > ...
> > I can't show you the kernel panic message, because I didn't found it in
> > the syslog, it is only on the screen,
> ...
>
On Sun, Feb 27, 2005 at 01:34:31PM -0600, Stephen Lord wrote:
Torben Viets wrote:
I have a RAID 5(md0) with 3 disks on md0 (chunk-size 128) there is a
...
I can't show you the kernel panic message, because I didn't found it in
the syslog, it is only on the screen,
...
Just on a
On Wed, Feb 23, 2005 at 04:26:58PM +0100, Sven Geggus wrote:
> Hi there,
>
> looks like xfsdumpis broken with recent 2.6.11-rc Kernels. 2.6.11-rc4 is the
> one I tried.
>
> Strange enough ist does seem to work _sometimes_, but it does not work
> most of the time.
>
> If it does not work I just
On Wed, Feb 23, 2005 at 04:26:58PM +0100, Sven Geggus wrote:
Hi there,
looks like xfsdumpis broken with recent 2.6.11-rc Kernels. 2.6.11-rc4 is the
one I tried.
Strange enough ist does seem to work _sometimes_, but it does not work
most of the time.
If it does not work I just get the
Hi Peter,
On Tue, Feb 15, 2005 at 12:49:45PM +1100, Peter Chubb wrote:
> Running Reaim-7 on a 4G ram disk with 4 processors on
> Itanium... Every few runs, as the multiprocessing level increases, we
> see 22 processes hung in sync(), all except one waiting in
> sync_filesystems() and that one
Hi Peter,
On Tue, Feb 15, 2005 at 12:49:45PM +1100, Peter Chubb wrote:
Running Reaim-7 on a 4G ram disk with 4 processors on
Itanium... Every few runs, as the multiprocessing level increases, we
see 22 processes hung in sync(), all except one waiting in
sync_filesystems() and that one waiting
On Wed, Feb 09, 2005 at 05:44:54PM +0300, Alexander Y. Fomichev wrote:
> On Wednesday 09 February 2005 04:29, Nathan Scott wrote:
> > Is that an O_SYNC write, do you know? Or a write to an inode
> > with the sync flag set?
>
> Yes, it is O_SYNC, as i can see from fcron sou
On Wed, Feb 09, 2005 at 05:44:54PM +0300, Alexander Y. Fomichev wrote:
On Wednesday 09 February 2005 04:29, Nathan Scott wrote:
Is that an O_SYNC write, do you know? Or a write to an inode
with the sync flag set?
Yes, it is O_SYNC, as i can see from fcron sources, and, no, kernel
OK
On Tue, Feb 08, 2005 at 08:51:36PM +0300, Alexander Y. Fomichev wrote:
> G' day
>
> It looks like XFS broken somewhere in 2.6.11-rc1,
> sadly i can't sand "right" bugreport, some facts only.
> Upgrade to 2.6.11-rc2 makes fcron non-working for me in case of
> crontabs directory is placed on XFS
On Tue, Feb 08, 2005 at 08:51:36PM +0300, Alexander Y. Fomichev wrote:
G' day
It looks like XFS broken somewhere in 2.6.11-rc1,
sadly i can't sand right bugreport, some facts only.
Upgrade to 2.6.11-rc2 makes fcron non-working for me in case of
crontabs directory is placed on XFS
Hi Anton,
On Thu, Jan 27, 2005 at 04:58:22PM -0800, Andrew Morton wrote:
> Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> >
> > What would you propose can I do to perform the required zeroing in a
> > deadlock safe manner whilst also ensuring that it cannot happen that a
> > concurrent
On Thu, Jan 27, 2005 at 08:51:45AM -0800, Chris Wedgwood wrote:
> On Thu, Jan 27, 2005 at 06:24:13PM +, Matthias-Christian Ott wrote:
> > I'll submit it to the mailinglist as a seperate patch, so Linus can
> > apply it to the current Kernel.
Chris' fix for this is in Linus' mail, queued to be
On Thu, Jan 27, 2005 at 08:51:45AM -0800, Chris Wedgwood wrote:
On Thu, Jan 27, 2005 at 06:24:13PM +, Matthias-Christian Ott wrote:
I'll submit it to the mailinglist as a seperate patch, so Linus can
apply it to the current Kernel.
Chris' fix for this is in Linus' mail, queued to be
Hi Anton,
On Thu, Jan 27, 2005 at 04:58:22PM -0800, Andrew Morton wrote:
Anton Altaparmakov [EMAIL PROTECTED] wrote:
What would you propose can I do to perform the required zeroing in a
deadlock safe manner whilst also ensuring that it cannot happen that a
concurrent -readpage() will
On Sat, Jan 22, 2005 at 08:29:30PM -0800, Matt Mackall wrote:
> On Sun, Jan 23, 2005 at 03:39:34AM +0100, Andi Kleen wrote:
>
> c) the three-way median selection does help avoid worst-case O(n^2)
> behavior, which might potentially be triggerable by users in places
> like XFS where this is used
On Sat, Jan 22, 2005 at 08:29:30PM -0800, Matt Mackall wrote:
On Sun, Jan 23, 2005 at 03:39:34AM +0100, Andi Kleen wrote:
c) the three-way median selection does help avoid worst-case O(n^2)
behavior, which might potentially be triggerable by users in places
like XFS where this is used
XFS's
1 - 100 of 110 matches
Mail list logo
