* Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
From: Baolin Wang @ 2016-06-08 2:00 UTC (permalink / raw)
To: Herbert Xu
Cc: Jens Axboe, Alasdair G Kergon, Mike Snitzer,
open list:DEVICE-MAPPER (LVM), David Miller, Eric Biggers,
Joonsoo Kim, tadeusz.struk, smueller, Masanari Iida, Shaohua Li,
Dan Williams, Martin K. Petersen, Sagi Grimberg, Kent Overstreet,
Keith Busch, Tejun Heo, Ming Lei, Mark Brown, Arnd Bergmann,
linux-crypto, linux-block,
open list:SOFTWARE RAID (Multiple Disks) SUPPORT, LKML
In-Reply-To: <20160607141613.GA2237@gondor.apana.org.au>
Hi Herbert,
On 7 June 2016 at 22:16, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Jun 07, 2016 at 08:17:05PM +0800, Baolin Wang wrote:
>> Now some cipher hardware engines prefer to handle bulk block rather than one
>> sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
>> the intermediate values (IV) by themselves in one bulk block. This means we
>> can increase the size of the request by merging request rather than always 512
>> bytes and thus increase the hardware engine processing speed.
>>
>> So introduce 'CRYPTO_ALG_BULK' flag to indicate this cipher can support bulk
>> mode.
>>
>> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
>
> Nack. As I said before, please do it using explicit IV generators
> like we do for IPsec.
OK. I would like to try your suggestion. Thanks.
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
Baolin.wang
Best Regards
^ permalink raw reply
* Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
From: Brad Campbell @ 2016-06-08 1:39 UTC (permalink / raw)
To: Phil Turmel, Marc MERLIN; +Cc: Sarah Newman, linux-raid@vger.kernel.org
In-Reply-To: <5756C67A.2040109@turmel.org>
On 07/06/16 21:04, Phil Turmel wrote:
> On 06/07/2016 12:51 AM, Marc MERLIN wrote:
>> Right, I understand now, good to know.
>> So I'll use badblocks next time I have this issue.
>
> Or just ignore them. You aren't using them, so they can't hurt you.
That's actually not necessarily true.
If you have a dud sector early on the disk (so before the start of the
RAID data) you will terminate every SMART long test in the first couple
of meg of the disk. So while a dud down there won't necessarily impact
your usage from a RAID perspective, it'll knacker your ability to
regularly check the disks in their entirety. SMART tests abort on the
first bad read.
It's ugly, but in the single instance I had that happen, I removed the
drive from the array, wrote zero to the entire disk and then added it
back. That forced a reallocation in the affected area.
Usually if it is in the RAID zone, a check scrub will clear it up.
Having said that I've had a very peculiar one here in the last couple of
days.
A WD 2TB Green drive with TLER set to 7 seconds. The first read would
error out in 7 seconds (as it should), but a second read succeeded.
After returning the error, the drive must have kept trying to recover in
the background and eventually succeeded and cached the result. So
subsequent reads were ok. After reading and writing enough to other
parts of the drive to flush the drives cache, the process would repeat.
In this case, it took about 3 check scrubs to actually hit the read
error and force a re-write.
^ permalink raw reply
* [PATCH] bcache: Remove deprecated create_workqueue
From: Bhaktipriya Shridhar @ 2016-06-07 20:27 UTC (permalink / raw)
To: Kent Overstreet, Shaohua Li, Jens Axboe, Eric Wheeler, Zheng Liu,
Hannes Reinecke, Jeff Moyer, Pekka Enberg, Al Viro
Cc: Tejun Heo, linux-bcache, linux-raid, linux-kernel
alloc_workqueue replaces deprecated create_workqueue().
Dedicated workqueues have been used since bcache_wq and moving_gc_wq
are workqueues for writes and are being used on a memory reclaim path.
WQ_MEM_RECLAIM has been set to ensure forward progress under memory
pressure.
Since there are only a fixed number of work items, explicit concurrency
limit is unnecessary here.
Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>
---
drivers/md/bcache/super.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index f5dbb4e..055c869 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -1518,7 +1518,8 @@ struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)
!(c->fill_iter = mempool_create_kmalloc_pool(1, iter_size)) ||
!(c->bio_split = bioset_create(4, offsetof(struct bbio, bio))) ||
!(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) ||
- !(c->moving_gc_wq = create_workqueue("bcache_gc")) ||
+ !(c->moving_gc_wq = alloc_workqueue("bcache_gc",
+ WQ_MEM_RECLAIM, 0)) ||
bch_journal_alloc(c) ||
bch_btree_cache_alloc(c) ||
bch_open_buckets_alloc(c) ||
@@ -2097,7 +2098,7 @@ static int __init bcache_init(void)
return bcache_major;
}
- if (!(bcache_wq = create_workqueue("bcache")) ||
+ if (!(bcache_wq = alloc_workqueue("bcache", WQ_MEM_RECLAIM, 0)) ||
!(bcache_kobj = kobject_create_and_add("bcache", fs_kobj)) ||
sysfs_create_files(bcache_kobj, files) ||
bch_request_init() ||
--
2.1.4
^ permalink raw reply related
* Re: mdadm 3.4-1, error msg. on boot - no /usr/lib/systemd/scripts/mdadm_env.sh
From: Jes Sorensen @ 2016-06-07 19:31 UTC (permalink / raw)
To: David C. Rankin; +Cc: mdraid
In-Reply-To: <5754CBF2.8000309@suddenlinkmail.com>
"David C. Rankin" <drankinatty@suddenlinkmail.com> writes:
> Neil, All,
>
> I'm chasing down the reason there is no
> /usr/lib/systemd/scripts/mdadm_env.sh provided with mdadm. This is
> more a curiosity really as mdmonitor continues to run, but it always
> throws an error at boot:
>
> Jun 05 17:12:47 valhalla systemd[454]: mdmonitor.service: Failed at step EXEC
> spawning /usr/lib/systemd/scripts/mdadm_env.sh: No such file or directory
>
> I have several Arch servers, all on mdadm 3.4-1. I ran into an issue
> a year or so ago with a boot error with mdmonitor due to my failure to
> provide MAILADDR in /etc/mdadm.com, but that has long since been
> corrected:
If you're running Arch Linux, you probably want to direct this question
to the Arch Linux maintainers.
Jes
^ permalink raw reply
* Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
From: Herbert Xu @ 2016-06-07 14:16 UTC (permalink / raw)
To: Baolin Wang
Cc: axboe, agk, snitzer, dm-devel, davem, ebiggers3, js1304,
tadeusz.struk, smueller, standby24x7, shli, dan.j.williams,
martin.petersen, sagig, kent.overstreet, keith.busch, tj,
ming.lei, broonie, arnd, linux-crypto, linux-block, linux-raid,
linux-kernel
In-Reply-To: <238ce3d506051c863300b90720c3e103175747cc.1465301616.git.baolin.wang@linaro.org>
On Tue, Jun 07, 2016 at 08:17:05PM +0800, Baolin Wang wrote:
> Now some cipher hardware engines prefer to handle bulk block rather than one
> sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
> the intermediate values (IV) by themselves in one bulk block. This means we
> can increase the size of the request by merging request rather than always 512
> bytes and thus increase the hardware engine processing speed.
>
> So introduce 'CRYPTO_ALG_BULK' flag to indicate this cipher can support bulk
> mode.
>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Nack. As I said before, please do it using explicit IV generators
like we do for IPsec.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
From: Phil Turmel @ 2016-06-07 14:14 UTC (permalink / raw)
To: Andreas Klauer, Marc MERLIN; +Cc: linux-raid@vger.kernel.org
In-Reply-To: <20160607135731.GA12550@metamorpher.de>
On 06/07/2016 09:57 AM, Andreas Klauer wrote:
> On Mon, Jun 06, 2016 at 10:41:13AM -0700, Marc MERLIN wrote:
>> Howdy, I have a raid 5 where one drive reported this:
>> 197 Current_Pending_Sector 0x0032 200 199 000 Old_age Always - 29
>
> RAID survival depends on healthy drives. This one does not look healthy.
> If the data on your RAID is important, I'd replace this drive. Getting
> this count back down to zero doesn't make it any more trustworthy.
That's excessively paranoid. You missed:
> 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
In other words, the totally normal accumulation of weak spots on his
disk aren't being cleaned up by overwriting as expected from raid
scrubbing. The vast majority of such flaws are successfully overwritten
and are not a problem. When they are overwritten and the drive firmware
decides to reallocate, then you can start worrying. I replace drives
when *reallocations* hit double digits, as my experience says they go to
hell quickly between 10 and 100.
FWIW, all of my troubles with drives were consumer-grade, mostly w/
scterc support, @ > 35k hours. I'll report to the list when my first
big batch of WD reds starts to die.
^ permalink raw reply
* Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
From: Marc MERLIN @ 2016-06-07 14:04 UTC (permalink / raw)
To: Phil Turmel, Andreas Klauer; +Cc: Sarah Newman, linux-raid@vger.kernel.org
In-Reply-To: <5756C67A.2040109@turmel.org>
On Tue, Jun 07, 2016 at 09:04:58AM -0400, Phil Turmel wrote:
> No, it doesn't keep track of anything the filesystem does. Look at the
> mdadm -E report for one of you member devices -- it shows the location
> of the superblock, the start location and size of the data area, and
> possibly information about the optional bitmap or bad block table.
> Areas outside the data area are not touched by check or repair scrubs.
Ok, that makes more sense. In my case, the md array is the entire drive,
minus partition and boot sector header, which is why I expected scanning
that would be good enough.
But as been pointed out already, it's very possible that the bad
sectors happened either on the parity drive that didn't get scanned, or
the unused space before the md array data actually starts on the drive.
> Or just ignore them. You aren't using them, so they can't hurt you.
> However, do look at the sector numbers in the SMART reports to make sure
> they aren't in the data area. (If you aren't using the whole disk for
The smart scan log for that drive didn't seem to show where said bad
sectores were (smartctl -a, log at the end). Either way, now they've
been remapped, so it's fine.
On Tue, Jun 07, 2016 at 03:57:31PM +0200, Andreas Klauer wrote:
> On Mon, Jun 06, 2016 at 10:41:13AM -0700, Marc MERLIN wrote:
> > Howdy, I have a raid 5 where one drive reported this:
> > 197 Current_Pending_Sector 0x0032 200 199 000 Old_age Always - 29
>
> RAID survival depends on healthy drives. This one does not look healthy.
> If the data on your RAID is important, I'd replace this drive. Getting
> this count back down to zero doesn't make it any more trustworthy.
Yeah, I hear what you're saying here. I usually do this actually. If
this drive grows another single bad sector, I will do this, but at this
time the hassle fo replacing the drive is not worth it yet.
The array is also used to hold offsite backups of backups of personal
data (not work stuff)
Thanks for the replies.
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
^ permalink raw reply
* Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
From: Andreas Klauer @ 2016-06-07 13:57 UTC (permalink / raw)
To: Marc MERLIN; +Cc: linux-raid@vger.kernel.org
In-Reply-To: <20160606174113.GI12382@merlins.org>
On Mon, Jun 06, 2016 at 10:41:13AM -0700, Marc MERLIN wrote:
> Howdy, I have a raid 5 where one drive reported this:
> 197 Current_Pending_Sector 0x0032 200 199 000 Old_age Always - 29
RAID survival depends on healthy drives. This one does not look healthy.
If the data on your RAID is important, I'd replace this drive. Getting
this count back down to zero doesn't make it any more trustworthy.
^ permalink raw reply
* Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
From: Mikael Abrahamsson @ 2016-06-07 13:56 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid@vger.kernel.org
In-Reply-To: <5756C67A.2040109@turmel.org>
On Tue, 7 Jun 2016, Phil Turmel wrote:
> Or just ignore them. You aren't using them, so they can't hurt you.
> However, do look at the sector numbers in the SMART reports to make sure
> they aren't in the data area. (If you aren't using the whole disk for
> mdadm, be sure to adjust for the partition start sector.) If they *are*
> in the data area, watch dmesg while scrubbing to see what's really
> happening.
I had a similar problem a few years back.
I seem to remember that there was a problem that the pending blocks were
in the superblock area, and these weren't written out when I did "check"
or "repair". I might be misremembering though, but I seem to remember I
had some kind of problem that when I tried to add the dive back in again,
it got a read error when trying to read the superblock.
They might have also been in the offset area. What I did was that I did a
--replace to another drive, then I dd:ed /dev/zero to the first gigabyte
of the drive, which removed the pending blocks. I then added the drive
back in.
Could someone confirm whether the entire (actually valuable portion) of
the superblock area is written out at any kind of frequency, or when a
check/repair is issued? If not, I think that would be a valuable thing to
do?
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
From: Phil Turmel @ 2016-06-07 13:04 UTC (permalink / raw)
To: Marc MERLIN; +Cc: Sarah Newman, linux-raid@vger.kernel.org
In-Reply-To: <20160607045122.GL12382@merlins.org>
On 06/07/2016 12:51 AM, Marc MERLIN wrote:
> On Mon, Jun 06, 2016 at 08:54:16PM -0400, Phil Turmel wrote:
>> Both processes only apply to the actual data area of each member device,
>> which is usually substantially less than the whole disk. Both processes
>> will read or write (or both) every data area sector.
>
> Mmmh, so it keeps track of how much of my block device is used by
> filesystem blocks and skips the rest? I didn't know that.
No, it doesn't keep track of anything the filesystem does. Look at the
mdadm -E report for one of you member devices -- it shows the location
of the superblock, the start location and size of the data area, and
possibly information about the optional bitmap or bad block table.
Areas outside the data area are not touched by check or repair scrubs.
> Right, I understand now, good to know.
> So I'll use badblocks next time I have this issue.
Or just ignore them. You aren't using them, so they can't hurt you.
However, do look at the sector numbers in the SMART reports to make sure
they aren't in the data area. (If you aren't using the whole disk for
mdadm, be sure to adjust for the partition start sector.) If they *are*
in the data area, watch dmesg while scrubbing to see what's really
happening.
Phil
^ permalink raw reply
* [RFC v4 4/4] crypto: Add the CRYPTO_ALG_BULK flag for ecb(aes) cipher
From: Baolin Wang @ 2016-06-07 12:17 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
In-Reply-To: <cover.1465301616.git.baolin.wang@linaro.org>
Since the ecb(aes) cipher does not need to handle the IV things for encryption
or decryption, that means it can support for bulk block when handling data.
Thus this patch adds the CRYPTO_ALG_BULK flag for ecb(aes) cipher to improve
the hardware aes engine's efficiency.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/crypto/omap-aes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index ce174d3..ab09429 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -804,7 +804,7 @@ static struct crypto_alg algs_ecb_cbc[] = {
.cra_priority = 300,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_KERN_DRIVER_ONLY |
- CRYPTO_ALG_ASYNC,
+ CRYPTO_ALG_ASYNC | CRYPTO_ALG_BULK,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct omap_aes_ctx),
.cra_alignmask = 0,
--
1.7.9.5
^ permalink raw reply related
* [RFC v4 3/4] md: dm-crypt: Introduce the bulk mode method when sending request
From: Baolin Wang @ 2016-06-07 12:17 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
In-Reply-To: <cover.1465301616.git.baolin.wang@linaro.org>
In now dm-crypt code, it is ineffective to map one segment (always one
sector) of one bio with just only one scatterlist at one time for hardware
crypto engine. Especially for some encryption mode (like ecb or xts mode)
cooperating with the crypto engine, they just need one initial IV or null
IV instead of different IV for each sector. In this situation We can consider
to use multiple scatterlists to map the whole bio and send all scatterlists
of one bio to crypto engine to encrypt or decrypt, which can improve the
hardware engine's efficiency.
With this optimization, On my test setup (beaglebone black board with ecb(aes)
cipher and dd testing) using 64KB I/Os on an eMMC storage device I saw about
127% improvement in throughput for encrypted writes, and about 206% improvement
for encrypted reads.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/md/dm-crypt.c | 159 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 158 insertions(+), 1 deletion(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 4f3cb35..0b1d452 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -33,6 +33,7 @@
#include <linux/device-mapper.h>
#define DM_MSG_PREFIX "crypt"
+#define DM_MAX_SG_LIST 512
/*
* context holding the current state of a multi-part conversion
@@ -142,6 +143,11 @@ struct crypt_config {
char *cipher;
char *cipher_string;
+ struct sg_table sgt_in;
+ struct sg_table sgt_out;
+ atomic_t sgt_init_done;
+ struct completion sgt_restart;
+
struct crypt_iv_operations *iv_gen_ops;
union {
struct iv_essiv_private essiv;
@@ -837,6 +843,141 @@ static u8 *iv_of_dmreq(struct crypt_config *cc,
crypto_skcipher_alignmask(any_tfm(cc)) + 1);
}
+static void crypt_init_sg_table(struct scatterlist *sgl)
+{
+ struct scatterlist *sg;
+ int i;
+
+ for_each_sg(sgl, sg, DM_MAX_SG_LIST, i) {
+ if (i < DM_MAX_SG_LIST - 1 && sg_is_last(sg))
+ sg_unmark_end(sg);
+ else if (i == DM_MAX_SG_LIST - 1)
+ sg_mark_end(sg);
+ }
+
+ for_each_sg(sgl, sg, DM_MAX_SG_LIST, i) {
+ memset(sg, 0, sizeof(struct scatterlist));
+
+ if (i == DM_MAX_SG_LIST - 1)
+ sg_mark_end(sg);
+ }
+}
+
+static void crypt_reinit_sg_table(struct crypt_config *cc)
+{
+ if (!cc->sgt_in.orig_nents || !cc->sgt_out.orig_nents)
+ return;
+
+ crypt_init_sg_table(cc->sgt_in.sgl);
+ crypt_init_sg_table(cc->sgt_out.sgl);
+
+ if (atomic_inc_and_test(&cc->sgt_init_done))
+ complete(&cc->sgt_restart);
+ atomic_set(&cc->sgt_init_done, 1);
+}
+
+static int crypt_alloc_sg_table(struct crypt_config *cc)
+{
+ unsigned int bulk_mode = skcipher_is_bulk_mode(any_tfm(cc));
+ int ret = 0;
+
+ if (!bulk_mode)
+ goto out_skip_alloc;
+
+ ret = sg_alloc_table(&cc->sgt_in, DM_MAX_SG_LIST, GFP_KERNEL);
+ if (ret)
+ goto out_skip_alloc;
+
+ ret = sg_alloc_table(&cc->sgt_out, DM_MAX_SG_LIST, GFP_KERNEL);
+ if (ret)
+ goto out_free_table;
+
+ init_completion(&cc->sgt_restart);
+ atomic_set(&cc->sgt_init_done, 1);
+ return 0;
+
+out_free_table:
+ sg_free_table(&cc->sgt_in);
+out_skip_alloc:
+ cc->sgt_in.orig_nents = 0;
+ cc->sgt_out.orig_nents = 0;
+
+ return ret;
+}
+
+static int crypt_convert_bulk_block(struct crypt_config *cc,
+ struct convert_context *ctx,
+ struct skcipher_request *req)
+{
+ struct bio *bio_in = ctx->bio_in;
+ struct bio *bio_out = ctx->bio_out;
+ unsigned int total_bytes = bio_in->bi_iter.bi_size;
+ unsigned int total_sg_in, total_sg_out;
+ struct scatterlist *sg_in, *sg_out;
+ struct dm_crypt_request *dmreq;
+ u8 *iv;
+ int r;
+
+ if (!cc->sgt_in.orig_nents || !cc->sgt_out.orig_nents)
+ return -EINVAL;
+
+ if (!atomic_dec_and_test(&cc->sgt_init_done)) {
+ wait_for_completion(&cc->sgt_restart);
+ reinit_completion(&cc->sgt_restart);
+ }
+
+ dmreq = dmreq_of_req(cc, req);
+ iv = iv_of_dmreq(cc, dmreq);
+ dmreq->iv_sector = ctx->cc_sector;
+ dmreq->ctx = ctx;
+
+ total_sg_in = blk_bio_map_sg(bdev_get_queue(bio_in->bi_bdev),
+ bio_in, cc->sgt_in.sgl);
+ if ((total_sg_in <= 0) || (total_sg_in > DM_MAX_SG_LIST)) {
+ DMERR("%s in sg map error %d, sg table nents[%d]\n",
+ __func__, total_sg_in, cc->sgt_in.orig_nents);
+ return -EINVAL;
+ }
+
+ ctx->iter_in.bi_size -= total_bytes;
+ sg_in = cc->sgt_in.sgl;
+ sg_out = cc->sgt_in.sgl;
+
+ if (bio_data_dir(bio_in) == READ)
+ goto set_crypt;
+
+ total_sg_out = blk_bio_map_sg(bdev_get_queue(bio_out->bi_bdev),
+ bio_out, cc->sgt_out.sgl);
+ if ((total_sg_out <= 0) || (total_sg_out > DM_MAX_SG_LIST)) {
+ DMERR("%s out sg map error %d, sg table nents[%d]\n",
+ __func__, total_sg_out, cc->sgt_out.orig_nents);
+ return -EINVAL;
+ }
+
+ ctx->iter_out.bi_size -= total_bytes;
+ sg_out = cc->sgt_out.sgl;
+
+set_crypt:
+ if (cc->iv_gen_ops) {
+ r = cc->iv_gen_ops->generator(cc, iv, dmreq);
+ if (r < 0)
+ return r;
+ }
+
+ atomic_set(&cc->sgt_init_done, 0);
+ skcipher_request_set_crypt(req, sg_in, sg_out, total_bytes, iv);
+
+ if (bio_data_dir(ctx->bio_in) == WRITE)
+ r = crypto_skcipher_encrypt(req);
+ else
+ r = crypto_skcipher_decrypt(req);
+
+ if (!r && cc->iv_gen_ops && cc->iv_gen_ops->post)
+ r = cc->iv_gen_ops->post(cc, iv, dmreq);
+
+ return r;
+}
+
static int crypt_convert_block(struct crypt_config *cc,
struct convert_context *ctx,
struct skcipher_request *req)
@@ -920,6 +1061,7 @@ static void crypt_free_req(struct crypt_config *cc,
static int crypt_convert(struct crypt_config *cc,
struct convert_context *ctx)
{
+ unsigned int bulk_mode;
int r;
atomic_set(&ctx->cc_pending, 1);
@@ -930,7 +1072,14 @@ static int crypt_convert(struct crypt_config *cc,
atomic_inc(&ctx->cc_pending);
- r = crypt_convert_block(cc, ctx, ctx->req);
+ bulk_mode = skcipher_is_bulk_mode(any_tfm(cc));
+ if (!bulk_mode) {
+ r = crypt_convert_block(cc, ctx, ctx->req);
+ } else {
+ r = crypt_convert_bulk_block(cc, ctx, ctx->req);
+ if (r == -EINVAL)
+ r = crypt_convert_block(cc, ctx, ctx->req);
+ }
switch (r) {
/*
@@ -1081,6 +1230,7 @@ static void crypt_dec_pending(struct dm_crypt_io *io)
if (io->ctx.req)
crypt_free_req(cc, io->ctx.req, base_bio);
+ crypt_reinit_sg_table(cc);
base_bio->bi_error = error;
bio_endio(base_bio);
}
@@ -1563,6 +1713,9 @@ static void crypt_dtr(struct dm_target *ti)
kzfree(cc->cipher);
kzfree(cc->cipher_string);
+ sg_free_table(&cc->sgt_in);
+ sg_free_table(&cc->sgt_out);
+
/* Must zero key material before freeing */
kzfree(cc);
}
@@ -1718,6 +1871,10 @@ static int crypt_ctr_cipher(struct dm_target *ti,
}
}
+ ret = crypt_alloc_sg_table(cc);
+ if (ret)
+ DMWARN("Allocate sg table for bulk mode failed");
+
ret = 0;
bad:
kfree(cipher_api);
--
1.7.9.5
^ permalink raw reply related
* [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
From: Baolin Wang @ 2016-06-07 12:17 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
In-Reply-To: <cover.1465301616.git.baolin.wang@linaro.org>
Now some cipher hardware engines prefer to handle bulk block rather than one
sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
the intermediate values (IV) by themselves in one bulk block. This means we
can increase the size of the request by merging request rather than always 512
bytes and thus increase the hardware engine processing speed.
So introduce 'CRYPTO_ALG_BULK' flag to indicate this cipher can support bulk
mode.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
include/crypto/skcipher.h | 7 +++++++
include/linux/crypto.h | 6 ++++++
2 files changed, 13 insertions(+)
diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h
index 0f987f5..d89d29a 100644
--- a/include/crypto/skcipher.h
+++ b/include/crypto/skcipher.h
@@ -519,5 +519,12 @@ static inline void skcipher_request_set_crypt(
req->iv = iv;
}
+static inline unsigned int skcipher_is_bulk_mode(struct crypto_skcipher *sk_tfm)
+{
+ struct crypto_tfm *tfm = crypto_skcipher_tfm(sk_tfm);
+
+ return crypto_tfm_alg_bulk(tfm);
+}
+
#endif /* _CRYPTO_SKCIPHER_H */
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 6e28c89..a315487 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -63,6 +63,7 @@
#define CRYPTO_ALG_DEAD 0x00000020
#define CRYPTO_ALG_DYING 0x00000040
#define CRYPTO_ALG_ASYNC 0x00000080
+#define CRYPTO_ALG_BULK 0x00000100
/*
* Set this bit if and only if the algorithm requires another algorithm of
@@ -623,6 +624,11 @@ static inline u32 crypto_tfm_alg_type(struct crypto_tfm *tfm)
return tfm->__crt_alg->cra_flags & CRYPTO_ALG_TYPE_MASK;
}
+static inline unsigned int crypto_tfm_alg_bulk(struct crypto_tfm *tfm)
+{
+ return tfm->__crt_alg->cra_flags & CRYPTO_ALG_BULK;
+}
+
static inline unsigned int crypto_tfm_alg_blocksize(struct crypto_tfm *tfm)
{
return tfm->__crt_alg->cra_blocksize;
--
1.7.9.5
^ permalink raw reply related
* [RFC v4 1/4] block: Introduce blk_bio_map_sg() to map one bio
From: Baolin Wang @ 2016-06-07 12:17 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
In-Reply-To: <cover.1465301616.git.baolin.wang@linaro.org>
In dm-crypt, it need to map one bio to scatterlist for improving the
hardware engine encryption efficiency. Thus this patch introduces the
blk_bio_map_sg() function to map one bio with scatterlists.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
block/blk-merge.c | 19 +++++++++++++++++++
include/linux/blkdev.h | 2 ++
2 files changed, 21 insertions(+)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 2613531..bca0609 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -417,6 +417,25 @@ single_segment:
}
/*
+ * Map a bio to scatterlist, return number of sg entries setup. Caller must
+ * make sure sg can hold bio segments entries and detach the bio from list.
+ */
+int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
+ struct scatterlist *sglist)
+{
+ struct scatterlist *sg = NULL;
+ int nsegs;
+
+ nsegs = __blk_bios_map_sg(q, bio, sglist, &sg);
+
+ if (sg)
+ sg_mark_end(sg);
+
+ return nsegs;
+}
+EXPORT_SYMBOL(blk_bio_map_sg);
+
+/*
* map a request to scatterlist, return number of sg entries setup. Caller
* must make sure sg can hold rq->nr_phys_segments entries
*/
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 3d9cf32..cbe31f9 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1024,6 +1024,8 @@ extern void blk_queue_write_cache(struct request_queue *q, bool enabled, bool fu
extern struct backing_dev_info *blk_get_backing_dev_info(struct block_device *bdev);
extern int blk_rq_map_sg(struct request_queue *, struct request *, struct scatterlist *);
+extern int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
+ struct scatterlist *sglist);
extern void blk_dump_rq_flags(struct request *, char *);
extern long nr_blockdev_pages(void);
--
1.7.9.5
^ permalink raw reply related
* [RFC v4 0/4] Introduce the bulk mode method when sending request to crypto layer
From: Baolin Wang @ 2016-06-07 12:17 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
This patchset will check if the cipher can support bulk mode, then dm-crypt
will handle different ways to send requests to crypto layer according to
cipher mode. For bulk mode, we can use sg table to map the whole bio and
send all scatterlists of one bio to crypto engine to encrypt or decrypt,
which can improve the hardware engine's efficiency.
Changes since v3:
- Some optimization for blk_bio_map_sg() function.
Changes since v2:
- Add one cipher user with CRYPTO_ALG_BULK flag to support bulk mode.
- Add one atomic variable to avoid the sg table race.
Changes since v1:
- Refactor the blk_bio_map_sg() function to avoid duplicated code.
- Move the sg table allocation to crypt_ctr_cipher() function to avoid memory
allocation in the IO path.
- Remove the crypt_sg_entry() function.
- Other optimization.
Baolin Wang (4):
block: Introduce blk_bio_map_sg() to map one bio
crypto: Introduce CRYPTO_ALG_BULK flag
md: dm-crypt: Introduce the bulk mode method when sending request
crypto: Add the CRYPTO_ALG_BULK flag for ecb(aes) cipher
block/blk-merge.c | 19 ++++++
drivers/crypto/omap-aes.c | 2 +-
drivers/md/dm-crypt.c | 159 ++++++++++++++++++++++++++++++++++++++++++++-
include/crypto/skcipher.h | 7 ++
include/linux/blkdev.h | 2 +
include/linux/crypto.h | 6 ++
6 files changed, 193 insertions(+), 2 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Re: Doubts on async_tx xor offload for raid5/6
From: Vinod Koul @ 2016-06-07 7:19 UTC (permalink / raw)
To: Vikas Aggarwal; +Cc: linux-raid, dmaengine
In-Reply-To: <CAOid5F-UWP-_jpA3XMFptfKa8=Gh7wBhhPZ1_DR_5UwJAxHriQ@mail.gmail.com>
On Thu, Jun 02, 2016 at 11:54:45AM +0530, Vikas Aggarwal wrote:
> Hi list,
> Will appreciate if someone can clear my doubts with "some theoretical
> examples". I am trying to improve XOR/GF offload for a multi-core SoC
> (currently it has single XOR/GF channel).
>
> 1) What is the purpose of device_prep_dma_interrupt callback ?
>
> 2) My driver currently polls for posting xor completions
> (dma_cookie_complete) and does'nt use device_prep_dma_interrupt
> callback at all. What gains/loss in terms of latency/cpu
> idleness/WRITE throughput I can expect by implementing this callback
> in my async_tx driver.
>
> 3) Purpose of DMA_ACK as I read - it is for higher layers to inform
> dma driver that descriptors can now be freed. Can someone explain this
> with an example as applicable with raid5/6 clients.
>
> 4) With example - why dma_run_dependencies(tx) needed after the
> hardware engine post completion for a descriptor.
>
> 5) Purpose of tx->callback(cb_arg) - again with an example from a
> raid5/6 offload perspective.
>
> I want to use offload engine efficiently with multithreaded raid5/6.
>
> I tried to dig through dma/drivers, crypto/async_xor.c, online
> archives, linux/Documentation etc but could not get satisfactory
> answers. Added two mail-lists as saw issues being discussed on both
> ones.
Did you read Documentation/crypto/async-tx-api.txt
Also you should refer to code in crpto for dmaengine usage and other
RAID examples.
It would help if you post the code and ask people what you are trying to
improve..
--
~Vinod
^ permalink raw reply
* Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
From: Roman Mamedov @ 2016-06-07 5:35 UTC (permalink / raw)
To: Marc MERLIN; +Cc: linux-raid@vger.kernel.org
In-Reply-To: <20160606174113.GI12382@merlins.org>
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
On Mon, 6 Jun 2016 10:41:13 -0700
Marc MERLIN <marc@merlins.org> wrote:
> However after the check is over, I still have 29 Current_Pending_Sector on
> that drive.
I had that once, even asked on this list (can't find that now), and it turned
out the pending sector(s) were in the gap between the start of the partition
and the start of the mdadm actual data (which turned out to be surprisingly
large) -- so naturally neither a check nor repair have ever tried to read or
write there.
> More drive details from before I ran badblocks (not an SMR drive):
> Device Model: WDC WD40EFRX-68WT0N0
> Serial Number: WD-WCC4E0642444
At least if it's out of warranty, consider checking the contact pads underside
the drive PCB and cleaning them. AFAIK the WD drives in particular are known to
develop rust there, which can lead to all sorts of problems including transient
"pending" sectors like that.
https://www.youtube.com/watch?v=qmT32VC22PU
https://www.youtube.com/watch?v=tDTt_yjYYQ8
--
With respect,
Roman
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
From: Marc MERLIN @ 2016-06-07 4:51 UTC (permalink / raw)
To: Phil Turmel; +Cc: Sarah Newman, linux-raid@vger.kernel.org
In-Reply-To: <57561B38.1070402@turmel.org>
On Mon, Jun 06, 2016 at 08:54:16PM -0400, Phil Turmel wrote:
> Repair doesn't even read the parity (and Q syndrome) blocks if it
> doesn't need them. It unconditionally recomputes and writes parity (and
> Q) blocks.
I see. So if it happens to rewrite a parity block that was unreadable
but that it didn't have to read, I won't even know it was unreadable to
start with (but only one change out of n of that happening in raid5)
> Both processes will compute and rewrite a block that reports a read error.
> > https://www.thomas-krenn.com/en/wiki/Mdadm_checkarray#Check_vs._Repair
> >
> > Or are you saying that check after getting a read error from one drive,
> > would not rewrite the bad block on that drive? I thought it did...
>
> They both do.
Thanks for confirming.
> Both processes only apply to the actual data area of each member device,
> which is usually substantially less than the whole disk. Both processes
> will read or write (or both) every data area sector.
Mmmh, so it keeps track of how much of my block device is used by
filesystem blocks and skips the rest? I didn't know that.
> Sectors that haven't ever been deliberately written and aren't read by
> normal mdadm processes are often the first to pop up in disk
> self-diagnostics. If you look at the sector offsets in the SMART data,
> I bet you find they're all outside the area mdadm is using.
Got it.
> > Whereas badblocks forced an unconditional rewrite of all blocks, and forced
> > the drive to re-allocate those "weak" blocks, even though it was able to
> > read them.
>
> Probably not. It got 'em because it wasn't limited to the data area.
Right, I understand now, good to know.
So I'll use badblocks next time I have this issue.
Thanks for clearing this up for me.
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
^ permalink raw reply
* Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
From: Phil Turmel @ 2016-06-07 0:54 UTC (permalink / raw)
To: Marc MERLIN, Sarah Newman; +Cc: linux-raid@vger.kernel.org
In-Reply-To: <20160606224401.GA6672@merlins.org>
On 06/06/2016 06:44 PM, Marc MERLIN wrote:
> From what I understand, the only difference between the 2 is that repair
> does not use the write-intent bitmap, but both will repair an error if
> found.
Repair doesn't even read the parity (and Q syndrome) blocks if it
doesn't need them. It unconditionally recomputes and writes parity (and
Q) blocks.
Both processes will compute and rewrite a block that reports a read error.
> https://www.thomas-krenn.com/en/wiki/Mdadm_checkarray#Check_vs._Repair
>
> Or are you saying that check after getting a read error from one drive,
> would not rewrite the bad block on that drive? I thought it did...
They both do.
> Either way, it seems that neither would have worked because while those
> blocks were marked as "need to be reallocated" by the drive, I think the
> kernel was actually able to read them without problem, so the md layer never
> saw anything and therefore never did anything either.
Both processes only apply to the actual data area of each member device,
which is usually substantially less than the whole disk. Both processes
will read or write (or both) every data area sector.
Sectors that haven't ever been deliberately written and aren't read by
normal mdadm processes are often the first to pop up in disk
self-diagnostics. If you look at the sector offsets in the SMART data,
I bet you find they're all outside the area mdadm is using.
Magnetism does slowly decay on drive platters, faster in the spots where
manufacturing didn't maintain the intended oxide thickness. Completely
normal and is the basis for URE specifications.
> Whereas badblocks forced an unconditional rewrite of all blocks, and forced
> the drive to re-allocate those "weak" blocks, even though it was able to
> read them.
Probably not. It got 'em because it wasn't limited to the data area.
Phil
^ permalink raw reply
* Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
From: Marc MERLIN @ 2016-06-06 22:44 UTC (permalink / raw)
To: Sarah Newman; +Cc: linux-raid@vger.kernel.org
In-Reply-To: <5755CA9F.6090807@prgmr.com>
On Mon, Jun 06, 2016 at 12:10:23PM -0700, Sarah Newman wrote:
> https://www.kernel.org/doc/Documentation/md.txt shows for sync_action
>
> check - A full check of redundancy was requested and is
> happening. This reads all blocks and checks
> them. A repair may also happen for some raid
> levels.
> repair - A full check and repair is happening. This is
> similar to 'resync', but was requested by the
> user, and the write-intent bitmap is NOT used to
> optimise the process.
>
> I think you wanted 'repair' not 'check'.
From what I understand, the only difference between the 2 is that repair
does not use the write-intent bitmap, but both will repair an error if
found.
https://www.thomas-krenn.com/en/wiki/Mdadm_checkarray#Check_vs._Repair
Or are you saying that check after getting a read error from one drive,
would not rewrite the bad block on that drive? I thought it did...
Either way, it seems that neither would have worked because while those
blocks were marked as "need to be reallocated" by the drive, I think the
kernel was actually able to read them without problem, so the md layer never
saw anything and therefore never did anything either.
Whereas badblocks forced an unconditional rewrite of all blocks, and forced
the drive to re-allocate those "weak" blocks, even though it was able to
read them.
Does that sound about right?
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
^ permalink raw reply
* Re: xfs_repair fails after trying to format log cycle?
From: Andrew Ryder @ 2016-06-06 19:37 UTC (permalink / raw)
To: Emmanuel Florac; +Cc: linux-raid, Brian Foster, xfs
In-Reply-To: <5755CCD7.1000104@shaw.ca>
On 06/06/2016 03:19 PM, Andrew Ryder wrote:
>
>
> On 06/06/2016 11:33 AM, Emmanuel Florac wrote:
>> Le Fri, 3 Jun 2016 22:28:54 -0400
>> Andrew Ryder <tireman@shaw.ca> écrivait:
>>
>>> Sorry to dig up old stuff here but after replacing hardware and
>>> pulling my hair out to no end, I traced the source of the problem out.
>>>
>>> On every drive in the array, the points on the PCB which the contacts
>>> for the drives motors and head/actuators make contact with were
>>> oxidized enough to cause the issue. I ended up pulling the PCB off
>>> each drive and cleaning them as well as cleaning out all other cable
>>> and drive connectors from the HBA outward and everything is happy
>>> again.
>>>
>>> http://s33.postimg.org/uhjmvw4dr/Not_Cleaned.jpg
>>> http://s33.postimg.org/xo94ieii7/Partial_Cleaned_1.jpg
>>> http://s33.postimg.org/hoqgyumgf/Partial_Cleaned_2.jpg
>>> http://s33.postimg.org/68k20t8a7/Partial_Cleaned_3.jpg
>>>
>>
>> Good job, that was quite unexpected :) Are you next to the
>> seashore?
>>
>
>
> No. I'm up in NW Ontario in Canada actually, far away from any salt
> water. I'm guessing it was from the combination of air
> pollutants/humidity and heat given the drives are not in the most
> hospitable environment esp during the summer ... but after cleaning the
> board contacts up as well as the esata cable ends/ports, its working
> great again.
>
> I'm beginning to think when I do replace any drives, after warranty is
> up on them, pull off the PCB, clean it up and coat the contacts with a
> good smearing of dielectric grease to keep the issue from happening.
>
> Makes me wonder how many other people out there suffer from the same
> issue given the amount of unresolved similar hw errors I've found while
> googling the errors..
>
> Thanks again,
> Andrew
>
One other thing might be worth noting, before I cleaned up the oxidation
on the drives boards, they would work fine if on dedicated SATA channels
off the mainboard, but when put on any sata port multiplier, it would do
nothing but act up. Which was really weird.
I'm assuming there must be some inherent sensitivity with sata PMP
chips/hw that make this more prevalent.. and I've tried both the old and
new version of SansDigital's TR8M's backplanes, 2 different sata PMP
HBAs (rocketraid 2722 and addonics older PCI 4 port sata pmp hba) as
well as an older addonics 3gbit sata port multiplier fan out board ..
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: xfs_repair fails after trying to format log cycle?
From: Andrew Ryder @ 2016-06-06 19:19 UTC (permalink / raw)
To: Emmanuel Florac; +Cc: linux-raid, Brian Foster, xfs
In-Reply-To: <20160606173336.027917f5@harpe.intellique.com>
On 06/06/2016 11:33 AM, Emmanuel Florac wrote:
> Le Fri, 3 Jun 2016 22:28:54 -0400
> Andrew Ryder <tireman@shaw.ca> écrivait:
>
>> Sorry to dig up old stuff here but after replacing hardware and
>> pulling my hair out to no end, I traced the source of the problem out.
>>
>> On every drive in the array, the points on the PCB which the contacts
>> for the drives motors and head/actuators make contact with were
>> oxidized enough to cause the issue. I ended up pulling the PCB off
>> each drive and cleaning them as well as cleaning out all other cable
>> and drive connectors from the HBA outward and everything is happy
>> again.
>>
>> http://s33.postimg.org/uhjmvw4dr/Not_Cleaned.jpg
>> http://s33.postimg.org/xo94ieii7/Partial_Cleaned_1.jpg
>> http://s33.postimg.org/hoqgyumgf/Partial_Cleaned_2.jpg
>> http://s33.postimg.org/68k20t8a7/Partial_Cleaned_3.jpg
>>
>
> Good job, that was quite unexpected :) Are you next to the
> seashore?
>
No. I'm up in NW Ontario in Canada actually, far away from any salt
water. I'm guessing it was from the combination of air
pollutants/humidity and heat given the drives are not in the most
hospitable environment esp during the summer ... but after cleaning the
board contacts up as well as the esata cable ends/ports, its working
great again.
I'm beginning to think when I do replace any drives, after warranty is
up on them, pull off the PCB, clean it up and coat the contacts with a
good smearing of dielectric grease to keep the issue from happening.
Makes me wonder how many other people out there suffer from the same
issue given the amount of unresolved similar hw errors I've found while
googling the errors..
Thanks again,
Andrew
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
From: Sarah Newman @ 2016-06-06 19:10 UTC (permalink / raw)
To: Marc MERLIN, linux-raid@vger.kernel.org
In-Reply-To: <20160606174113.GI12382@merlins.org>
On 06/06/2016 10:41 AM, Marc MERLIN wrote:
> Howdy, I have a raid 5 where one drive reported this:
> 197 Current_Pending_Sector 0x0032 200 199 000 Old_age Always - 29
>
> So I did this:
> myth:~# echo check > /sys/block/md5/md/sync_action
> [173947.749761] md: data-check of RAID array md5
> (...)
> [370316.769230] md: md5: data-check done.
>
> My understanding was that it was supposed to read every block of every
> drive, and if some blocks were unreadable, use parity to rewrite them on
> some fresh backup blocks.
> If a block returned garbage instead, md5 cannot fix this not knowing which
> block is wrong, but I'm assuming the check would have failed with an error.
https://www.kernel.org/doc/Documentation/md.txt shows for sync_action
check - A full check of redundancy was requested and is
happening. This reads all blocks and checks
them. A repair may also happen for some raid
levels.
repair - A full check and repair is happening. This is
similar to 'resync', but was requested by the
user, and the write-intent bitmap is NOT used to
optimise the process.
I think you wanted 'repair' not 'check'.
--Sarah
^ permalink raw reply
* restarting raid arrays with uuid
From: Bryan Hepworth @ 2016-06-06 18:54 UTC (permalink / raw)
To: linux-raid@vger.kernel.org
Hi All
I'm not entirely sure this is rescuable. This is an old system that was kept on for scratch storage space, unfortunately it was discovered some data hadn't moved out of this area. The arrays disappeared after taking them offline and rebooting the machine.
I've checked /etc/mdadm.conf
And mdadm --examine across all of the disks
I've assembled from uuid
Ran /proc/mdstat
Any suggestions as to what to try next?
Thanks
Bryan
[root@igmimager dev]# cat /etc/mdadm.conf
ARRAY /dev/md0 metadata=1.2 name=igmimager.ncl.ac.uk:129 UUID=1dc7f560:edbfe144:0531da73:f239c583
ARRAY /dev/md1 metadata=1.2 name=inscribe_data1 UUID=2b00561d:25e97d49:65d13ea0:63aba0b7
ARRAY /dev/md2 metadata=1.2 name=igmimager.ncl.ac.uk:128 UUID=3aee46d0:ced811c7:287c9e2e:c9fcb98d
ARRAY /dev/md3 metadata=1.2 name=inscribe_data5 UUID=4108db00:e338d0eb:64f1c8c0:7c5dd4d2
ARRAY /dev/md4 metadata=1.2 name=igmimager.ncl.ac.uk:0 UUID=bc69e915:891c1a98:083d6b8d:8d99151f
ARRAY /dev/md5 metadata=1.2 name=inscribe_data4 UUID=f83ae16b:c7cf278a:199a0085:d8f68936
[root@igmimager dev]#
[root@igmimager etc]# mdadm --assemble /dev/md0 --uuid 1dc7f560:edbfe144:0531da73:f239c583
[root@igmimager etc]# mdadm --assemble /dev/md1 --uuid 2b00561d:25e97d49:65d13ea0:63aba0b7
[root@igmimager etc]# mdadm --assemble /dev/md2 --uuid 3aee46d0:ced811c7:287c9e2e:c9fcb98d
[root@igmimager etc]# mdadm --assemble /dev/md3 --uuid 4108db00:e338d0eb:64f1c8c0:7c5dd4d2
[root@igmimager etc]# mdadm --assemble /dev/md4 --uuid bc69e915:891c1a98:083d8f68936
mdadm: Bad uuid: bc69e915:891c1a98:083d8f68936
[root@igmimager etc]# mdadm --assemble /dev/md4 --uuid bc69e915:891c1a98:083d6b8d:8d99151f
mdadm: Found some drive for an array that is already active: /dev/md4
mdadm: giving up.
[root@igmimager etc]# mdadm --assemble /dev/md5 --uuid f83ae16b:c7cf278a:199a0085:d8f68936
[root@igmimager etc]# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md3 : active raid5 sdi1[0] sdl1[4] sdk1[2] sdj1[1]
5860142592 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 0/15 pages [0KB], 65536KB chunk
md4 : active raid5 sdn[2] sdp[0] sdo[1]
5860148736 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_]
bitmap: 9/15 pages [36KB], 65536KB chunk
unused devices: <none>
[root@igmimager dev]# ls
autofs MAKEDEV sda sg18 tty22 tty6
block mapper sdb sg19 tty23 tty60
bsg mcelog sdc sg2 tty24 tty61
bus md sdd sg20 tty25 tty62
cdrom md3 sde sg21 tty26 tty63
cdrw md4 sdf sg22 tty27 tty7
char mem sdg sg23 tty28 tty8
console mpt2ctl sdh sg24 tty29 tty9
core net sdi sg25 tty3 ttyS0
cpu network_latency sdi1 sg26 tty30 ttyS1
cpu_dma_latency network_throughput sdj sg27 tty31 ttyS2
crash null sdj1 sg3 tty32 ttyS3
disk nvram sdk sg4 tty33 uinput
dm-0 oldmem sdk1 sg5 tty34 urandom
dm-1 parport0 sdl sg6 tty35 usbmon0
dm-2 port sdl1 sg7 tty36 usbmon1
dvd ppp sdm sg8 tty37 usbmon2
dvdrw ptmx sdn sg9 tty38 usbmon3
fb pts sdo shm tty39 vcs
fb0 ram0 sdp snapshot tty4 vcs1
fd ram1 sdq sr0 tty40 vcs2
full ram10 sdr stderr tty41 vcs3
fuse ram11 sds stdin tty42 vcs4
hpet ram12 sdt stdout tty43 vcs5
hugepages ram13 sdu systty tty44 vcs6
hvc0 ram14 sdv tty tty45 vcs7
input ram15 sdw tty0 tty46 vcsa
kmsg ram2 sdx tty1 tty47 vcsa1
log ram3 sdy tty10 tty48 vcsa2
loop0 ram4 sdy1 tty11 tty49 vcsa3
loop1 ram5 sdy2 tty12 tty5 vcsa4
loop2 ram6 sg0 tty13 tty50 vcsa5
loop3 ram7 sg1 tty14 tty51 vcsa6
loop4 ram8 sg10 tty15 tty52 vcsa7
loop5 ram9 sg11 tty16 tty53 vga_arbiter
loop6 random sg12 tty17 tty54 vg_igmimager
loop7 raw sg13 tty18 tty55 watchdog
lp0 root sg14 tty19 tty56 zero
lp1 rtc sg15 tty2 tty57
lp2 rtc0 sg16 tty20 tty58
lp3 scd0 sg17 tty21 tty59
[root@igmimager dev]# mdadm --examine /dev/sda
/dev/sda:
MBR Magic : aa55
Partition[0] : 3907029167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sdb
/dev/sdb:
MBR Magic : aa55
Partition[0] : 3907029167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sdc
/dev/sdc:
MBR Magic : aa55
Partition[0] : 3907029167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sdd
/dev/sdd:
MBR Magic : aa55
Partition[0] : 3907029167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sde
/dev/sde:
MBR Magic : aa55
Partition[0] : 1953525167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sdf
/dev/sdf:
MBR Magic : aa55
Partition[0] : 1953525167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sdg
/dev/sdg:
MBR Magic : aa55
Partition[0] : 1953525167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sdh
/dev/sdh:
MBR Magic : aa55
Partition[0] : 1953525167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sdi
/dev/sdi:
MBR Magic : aa55
Partition[0] : 3907024002 sectors at 63 (type fd)
[root@igmimager dev]# mdadm --examine /dev/sdi1
/dev/sdi1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 4108db00:e338d0eb:64f1c8c0:7c5dd4d2
Name : inscribe_data5
Creation Time : Tue Nov 4 14:29:13 2014
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3906761858 (1862.89 GiB 2000.26 GB)
Array Size : 5860142592 (5588.67 GiB 6000.79 GB)
Used Dev Size : 3906761728 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=130 sectors
State : clean
Device UUID : dacbe3a5:6eaa2eb8:af08f6e1:4c328ba0
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Jun 6 09:23:33 2016
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : c47214c8 - correct
Events : 4082
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
[root@igmimager dev]# mdadm --examine /dev/sdj
/dev/sdj:
MBR Magic : aa55
Partition[0] : 3907024002 sectors at 63 (type fd)
[root@igmimager dev]# mdadm --examine /dev/sdj1
/dev/sdj1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 4108db00:e338d0eb:64f1c8c0:7c5dd4d2
Name : inscribe_data5
Creation Time : Tue Nov 4 14:29:13 2014
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3906761858 (1862.89 GiB 2000.26 GB)
Array Size : 5860142592 (5588.67 GiB 6000.79 GB)
Used Dev Size : 3906761728 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=130 sectors
State : clean
Device UUID : cf8bb995:c90196ed:3596b09b:daaf0e95
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Jun 6 09:23:33 2016
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 97ed372d - correct
Events : 4082
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
[root@igmimager dev]# mdadm --examine /dev/sdk
/dev/sdk:
MBR Magic : aa55
Partition[0] : 3907024002 sectors at 63 (type fd)
[root@igmimager dev]# mdadm --examine /dev/sdk1
/dev/sdk1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 4108db00:e338d0eb:64f1c8c0:7c5dd4d2
Name : inscribe_data5
Creation Time : Tue Nov 4 14:29:13 2014
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3906761858 (1862.89 GiB 2000.26 GB)
Array Size : 5860142592 (5588.67 GiB 6000.79 GB)
Used Dev Size : 3906761728 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=130 sectors
State : clean
Device UUID : bb4bec12:c5ab5c9d:c06e01aa:bff93d27
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Jun 6 09:23:33 2016
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 6566c385 - correct
Events : 4082
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
[root@igmimager dev]# mdadm --examine /dev/sdl
/dev/sdl:
MBR Magic : aa55
Partition[0] : 3907024002 sectors at 63 (type fd)
[root@igmimager dev]# mdadm --examine /dev/sdl1
/dev/sdl1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 4108db00:e338d0eb:64f1c8c0:7c5dd4d2
Name : inscribe_data5
Creation Time : Tue Nov 4 14:29:13 2014
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3906761858 (1862.89 GiB 2000.26 GB)
Array Size : 5860142592 (5588.67 GiB 6000.79 GB)
Used Dev Size : 3906761728 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=130 sectors
State : clean
Device UUID : bd44fe34:7e930cb8:833ca67b:feb4479a
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Jun 6 09:23:33 2016
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : e6d73254 - correct
Events : 4082
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 3
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
[root@igmimager dev]# mdadm --examine /dev/sdm
/dev/sdm:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : bc69e915:891c1a98:083d6b8d:8d99151f
Name : igmimager.ncl.ac.uk:0 (local to host igmimager.ncl.ac.uk)
Creation Time : Fri Aug 15 10:07:25 2014
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
Array Size : 5860148736 (5588.67 GiB 6000.79 GB)
Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=1200 sectors
State : clean
Device UUID : 5c9e7c6d:1c153f07:dda9dbe8:4b5ee6ae
Internal Bitmap : 8 sectors from superblock
Update Time : Thu May 28 11:23:56 2015
Checksum : 5b0ecf59 - correct
Events : 293
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 3
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
[root@igmimager dev]# mdadm --examine /dev/sdn
/dev/sdn:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : bc69e915:891c1a98:083d6b8d:8d99151f
Name : igmimager.ncl.ac.uk:0 (local to host igmimager.ncl.ac.uk)
Creation Time : Fri Aug 15 10:07:25 2014
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
Array Size : 5860148736 (5588.67 GiB 6000.79 GB)
Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=1200 sectors
State : clean
Device UUID : 6565a1ae:3964efa8:8c17f442:dd1afbec
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Jun 6 09:24:00 2016
Checksum : d800f44f - correct
Events : 40791
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : AAA. ('A' == active, '.' == missing, 'R' == replacing)
[root@igmimager dev]# mdadm --examine /dev/sdo
/dev/sdo:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : bc69e915:891c1a98:083d6b8d:8d99151f
Name : igmimager.ncl.ac.uk:0 (local to host igmimager.ncl.ac.uk)
Creation Time : Fri Aug 15 10:07:25 2014
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
Array Size : 5860148736 (5588.67 GiB 6000.79 GB)
Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=1200 sectors
State : clean
Device UUID : 4db2ac90:09cf877c:11544b5b:deb24f24
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Jun 6 09:24:00 2016
Checksum : dd50808b - correct
Events : 40791
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AAA. ('A' == active, '.' == missing, 'R' == replacing)
[root@igmimager dev]# mdadm --examine /dev/sdp
/dev/sdp:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : bc69e915:891c1a98:083d6b8d:8d99151f
Name : igmimager.ncl.ac.uk:0 (local to host igmimager.ncl.ac.uk)
Creation Time : Fri Aug 15 10:07:25 2014
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
Array Size : 5860148736 (5588.67 GiB 6000.79 GB)
Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=1200 sectors
State : clean
Device UUID : 7a8f2d04:b51d004e:bcdc3dbf:0ae37b15
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Jun 6 09:24:00 2016
Checksum : 7768653a - correct
Events : 40791
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AAA. ('A' == active, '.' == missing, 'R' == replacing)
[root@igmimager dev]# mdadm --examine /dev/sdq
/dev/sdq:
MBR Magic : aa55
Partition[0] : 1953525167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sdr
/dev/sdr:
MBR Magic : aa55
Partition[0] : 1953525167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sds
/dev/sds:
MBR Magic : aa55
Partition[0] : 3907029167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sdt
/dev/sdt:
MBR Magic : aa55
Partition[0] : 1953525167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sdu
/dev/sdu:
MBR Magic : aa55
Partition[0] : 3907029167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sdv
/dev/sdv:
MBR Magic : aa55
Partition[0] : 3907029167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sdw
/dev/sdw:
MBR Magic : aa55
Partition[0] : 3907029167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sdx
/dev/sdx:
MBR Magic : aa55
Partition[0] : 3907029167 sectors at 1 (type ee)
[root@igmimager dev]# mdadm --examine /dev/sdy
/dev/sdy:
MBR Magic : aa55
Partition[0] : 1024000 sectors at 2048 (type 83)
Partition[1] : 487254016 sectors at 1026048 (type 8e)
[root@igmimager dev]# mdadm --examine /dev/sdy1
mdadm: No md superblock detected on /dev/sdy1.
[root@igmimager dev]# mdadm --examine /dev/sdy2
mdadm: No md superblock detected on /dev/sdy2.
[root@igmimager dev]#
^ permalink raw reply
* Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
From: Marc MERLIN @ 2016-06-06 17:41 UTC (permalink / raw)
To: linux-raid@vger.kernel.org
Howdy, I have a raid 5 where one drive reported this:
197 Current_Pending_Sector 0x0032 200 199 000 Old_age Always - 29
So I did this:
myth:~# echo check > /sys/block/md5/md/sync_action
[173947.749761] md: data-check of RAID array md5
(...)
[370316.769230] md: md5: data-check done.
My understanding was that it was supposed to read every block of every
drive, and if some blocks were unreadable, use parity to rewrite them on
some fresh backup blocks.
If a block returned garbage instead, md5 cannot fix this not knowing which
block is wrong, but I'm assuming the check would have failed with an error.
However after the check is over, I still have 29 Current_Pending_Sector on
that drive.
Since raid check succeeded, I'm going to assume that the sectors were
readable and did not return garbage, or I'd have gotten a parity mismatch
error.
Should then assume that either
1) the smart counter/logic is wrong?
2) the pending sectors started returning correct data again, so linux md has
no idea those blocks are "weak" and I have no easy way to forcibly remap
them.
3) the bad blocks did get remapped somehow, but the smart counter did not get
reset due to a firmware bug
4) other
After 2 days of testing with badblocks, it seems that it's #2, and I'm
not sure if there is anything raid check could have done (probably not)
Since raid check didn't do the job I was hoping for, I ran this instead:
myth:~# badblocks -nsv /dev/sdg
Checking for bad blocks in non-destructive read-write mode
From block 0 to 3907018583
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: 57.87% done, 22:24:15 elapsed. (0/0/0 errors))
And this worked:
197 Current_Pending_Sector 0x0032 200 199 000 Old_age Always - 0
strangely, I also have:
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
I guess this means that my drive's auto reallocation logic is faulty and
that it will not re-allocate blocks that are weak, even after it was
able to read them.
Does that sound correct?
More drive details from before I ran badblocks (not an SMR drive):
Device Model: WDC WD40EFRX-68WT0N0
Serial Number: WD-WCC4E0642444
LU WWN Device Id: 5 0014ee 2b437e9a6
Firmware Version: 80.00A80
User Capacity: 4,000,787,030,016 bytes [4.00 TB]
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 1617
3 Spin_Up_Time 0x0027 175 173 021 Pre-fail Always - 8250
4 Start_Stop_Count 0x0032 094 094 000 Old_age Always - 6773
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0
9 Power_On_Hours 0x0032 074 074 000 Old_age Always - 19092
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 158
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 91
193 Load_Cycle_Count 0x0032 182 182 000 Old_age Always - 54642
194 Temperature_Celsius 0x0022 121 103 000 Old_age Always - 31
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 199 000 Old_age Always - 29
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 199 000 Old_age Always - 2
200 Multi_Zone_Error_Rate 0x0008 200 189 000 Old_age Offline - 0
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 19081 -
# 2 Short offline Completed without error 00% 19057 -
# 3 Short offline Completed without error 00% 19035 -
# 4 Short offline Completed without error 00% 18984 -
# 5 Extended offline Completed without error 00% 18974 -
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox