On 10/24/14 21:51, Martin K. Petersen wrote:
"Michael" == Michael L Semon writes:
Michael> There was nothing regarding integrity in /sys/block/sda. I was
Michael> under the impression that both bio integrity and T10 checksums
Michael> require hardware support fro
On 10/24/14 21:51, Martin K. Petersen wrote:
Michael == Michael L Semon mlsemo...@gmail.com writes:
Michael There was nothing regarding integrity in /sys/block/sda. I was
Michael under the impression that both bio integrity and T10 checksums
Michael require hardware support from good hardware
On 10/24/14 15:54, Martin K. Petersen wrote:
"Michael" == Michael L Semon writes:
Michael> This week, a simple `dc3dd wipe=/dev/sda5` operation had speeds
Michael> cut from 10-15 MB/s down to less than 1.8 MB/s. With this
Michael> method, syncs took so long that magic Sys
Hi! I have an old i686 Pentium 4 that I use for xfstests. To better keep
integrity, write cache is disabled on an old 60-"megabyte" IDE HDD. The
PC runs slackware-current, doing a `git pull` of the kernel and
xfs-oss/for-next once or twice a week.
This week, a simple `dc3dd wipe=/dev/sda5`
Hi! I have an old i686 Pentium 4 that I use for xfstests. To better keep
integrity, write cache is disabled on an old 60-megabyte IDE HDD. The
PC runs slackware-current, doing a `git pull` of the kernel and
xfs-oss/for-next once or twice a week.
This week, a simple `dc3dd wipe=/dev/sda5`
On 10/24/14 15:54, Martin K. Petersen wrote:
Michael == Michael L Semon mlsemo...@gmail.com writes:
Michael This week, a simple `dc3dd wipe=/dev/sda5` operation had speeds
Michael cut from 10-15 MB/s down to less than 1.8 MB/s. With this
Michael method, syncs took so long that magic SysRq
On Wed, 9 Apr 2014, Jason Low wrote:
> On Wed, 2014-04-09 at 15:19 +0300, Kirill A. Shutemov wrote:
> > On Sun, Apr 06, 2014 at 01:12:14AM -0400, Michael L. Semon wrote:
> > > Hi! Starting early in this merge window for 3.15, lockdep has been
> > > giving me
On Wed, 9 Apr 2014, Jason Low wrote:
On Wed, 2014-04-09 at 15:19 +0300, Kirill A. Shutemov wrote:
On Sun, Apr 06, 2014 at 01:12:14AM -0400, Michael L. Semon wrote:
Hi! Starting early in this merge window for 3.15, lockdep has been
giving me trouble. Normally, a splat will happen
Hi! Starting early in this merge window for 3.15, lockdep has been
giving me trouble. Normally, a splat will happen, lockdep will shut
itself off, and my i686 Pentium 4 PC will continue. Now, after the
splat, it will allow one key of input at either a VGA console or over
serial. After that,
Hi! Starting early in this merge window for 3.15, lockdep has been
giving me trouble. Normally, a splat will happen, lockdep will shut
itself off, and my i686 Pentium 4 PC will continue. Now, after the
splat, it will allow one key of input at either a VGA console or over
serial. After that,
ple errors in reviewing the patches converting jfs
to use the generic posix ACL function. Setting ACL's currently
fails with -EOPNOTSUPP.
Signed-off-by: Dave Kleikamp
Reported-by: Michael L. Semon
Cc: Christoph Hellwig
---
fs/jfs/xattr.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletion
in reviewing the patches converting jfs
to use the generic posix ACL function. Setting ACL's currently
fails with -EOPNOTSUPP.
Signed-off-by: Dave Kleikamp dave.kleik...@oracle.com
Reported-by: Michael L. Semon mlsemo...@gmail.com
Cc: Christoph Hellwig h...@lst.de
---
fs/jfs/xattr.c | 14 +++---
1
Hi! Since a particular aio-next merge during the kernel 3.12
development cycle, I've had issues with AIO and xfstests. The typical
stalled test would end up stalled, and a SysRq-g would help me get to
this stack trace (just for context, the lockdep I'm reporting is one
page down):
kdb> btp
Hi! Since a particular aio-next merge during the kernel 3.12
development cycle, I've had issues with AIO and xfstests. The typical
stalled test would end up stalled, and a SysRq-g would help me get to
this stack trace (just for context, the lockdep I'm reporting is one
page down):
kdb btp
, though, in case it's still needed.
Michael
On Tue, Jul 9, 2013 at 9:59 PM, Dave Jones wrote:
> On Tue, Jul 09, 2013 at 09:51:32PM -0400, Michael L. Semon wrote:
>
> > kernel: [ 2580.395592] vmap allocation for size 20480 failed: use
> vmalloc= to increase size.
> > kernel: [
, though, in case it's still needed.
Michael
On Tue, Jul 9, 2013 at 9:59 PM, Dave Jones da...@redhat.com wrote:
On Tue, Jul 09, 2013 at 09:51:32PM -0400, Michael L. Semon wrote:
kernel: [ 2580.395592] vmap allocation for size 20480 failed: use
vmalloc=size to increase size.
kernel
Hi! I'm doing volunteer testing of xfstests and was sent here to
ask about this issue. I apologize in advance if the problem has
already been solved...
I've been testing XFS from various git kernels on 32-bit Pentium 4
and Pentium III PCs. There was an issue with xfstests test xfs/167,
Hi! I'm doing volunteer testing of xfstests and was sent here to
ask about this issue. I apologize in advance if the problem has
already been solved...
I've been testing XFS from various git kernels on 32-bit Pentium 4
and Pentium III PCs. There was an issue with xfstests test xfs/167,
18 matches
Mail list logo
