gmane.linux.raid

[PATCH 2/2] md/raid456:Add interface for contorling eject rdev when re-write failed.

majianpeng — 2012-05-26T02:54:50

When RAID-4/5/6 readed fail and if raid did not degrade,it will
compute,re-write and re-read.If re-read error,it will to eject the rdev.
If so, raid will recovery.
At present,disks are larger,so recovery will take a long time.
It will increasing the opportunity to become failed.
So add a interface using sysfs,to control the number of max re-write
errors.
The default value is zero,as the origin action which met re-write
error to eject the rdev.

Signed-off-by: majianpeng <majianpeng< at >gmail.com>
---
 drivers/md/md.c    |   35 +++++++++++++++++++++++++++++++++++
 drivers/md/md.h    |    2 ++
 drivers/md/raid5.c |   20 ++++++++++++--------
 3 files changed, 49 insertions(+), 8 deletions(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 1c2f904..cd399ec 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
< at >< at > -81,6 +81,13 < at >< at > static struct workqueue_struct *md_misc_wq;
  */
 #define MD_DEFAULT_MAX_CORRECTED_READ_ERRORS 20
 /*
+ * Current RAID-4,5,6 read failed and then try to compter and rewrite,
+ * reread,if raid did not degrad.But when reread failed,we'll set
+ * badsector before ejecting it from array.
+ * By default if reread failed, we'll eject the rdev.
+ */
+#define MD_DEFAULT_MAX_UNCORRECTED_READ_ERRORS 0
+/*
  * Current RAID-1,4,5 parallel reconstruction 'guaranteed speed limit'
  * is 1000 KB/sec, so the extra system load does not show up that much.
  * Increase it if you want to have more _guaranteed_ speed. Note that
< at >< at > -3260,6 +3267,7 < at >< at > int md_rdev_init(struct md_rdev *rdev)
 atomic_set(&rdev->nr_pending, 0);
 atomic_set(&rdev->read_errors, 0);
 atomic_set(&rdev->corrected_errors, 0);
+atomic_set(&rdev->uncorrected_errors, 0);
 
 INIT_LIST_HEAD(&rdev->same_set);
 init_waitqueue_head(&rdev->blocked_wait);
< at >< at > -4051,6 +4059,30 < at >< at > __ATTR(max_read_errors, S_IRUGO|S_IWUSR, max_corrected_read_errors_show,
 max_corrected_read_errors_store);
 
 static ssize_t
+max_uncorrected_read_errors_show(struct mddev *mddev, char *page) {
+return sprintf(page, "%d\n",
+atomic_read(&mddev->max_uncorr_read_errors));
+}
+
+static ssize_t
+max_uncorrected_read_errors_store(struct mddev *mddev, const char *buf, size_t len)
+{
+char *e;
+unsigned long n = simple_strtoul(buf, &e, 10);
+
+if (*buf && (*e == 0 || *e == '\n')) {
+atomic_set(&mddev->max_uncorr_read_errors, n);
+return len;
+}
+return -EINVAL;
+}
+
+static struct md_sysfs_entry max_uncorr_read_errors =
+__ATTR(max_uncorr_read_errors, S_IRUGO|S_IWUSR,
+max_uncorrected_read_errors_show,
+max_uncorrected_read_errors_store);
+
+static ssize_t
 null_show(struct mddev *mddev, char *page)
 {
 return -EINVAL;
< at >< at > -4744,6 +4776,7 < at >< at > static struct attribute *md_redundancy_attrs[] = {
 &md_suspend_hi.attr,
 &md_bitmap.attr,
 &md_degraded.attr,
+&max_uncorr_read_errors.attr,
 NULL,
 };
 static struct attribute_group md_redundancy_group = {
< at >< at > -5166,6 +5199,8 < at >< at > int md_run(struct mddev *mddev)
  atomic_set(&mddev->writes_pending,0);
 atomic_set(&mddev->max_corr_read_errors,
    MD_DEFAULT_MAX_CORRECTED_READ_ERRORS);
+atomic_set(&mddev->max_uncorr_read_errors,
+   MD_DEFAULT_MAX_UNCORRECTED_READ_ERRORS);
 mddev->safemode = 0;
 mddev->safemode_timer.function = md_safemode_timeout;
 mddev->safemode_timer.data = (unsigned long) mddev;
diff --git a/drivers/md/md.h b/drivers/md/md.h
index 7b4a3c3..4a9ee85 100644
--- a/drivers/md/md.h
+++ b/drivers/md/md.h
< at >< at > -104,6 +104,7 < at >< at > struct md_rdev {
    * for reporting to userspace and storing
    * in superblock.
    */
+atomic_tuncorrected_errors;
 struct work_struct del_work;/* used for delayed sysfs removal */
 
 struct sysfs_dirent *sysfs_state; /* handle for 'state'
< at >< at > -408,6 +409,7 < at >< at > struct mddev {
 } bitmap_info;
 
 atomic_t max_corr_read_errors; /* max read retries */
+atomic_tmax_uncorr_read_errors;
 struct list_headall_mddevs;
 
 struct attribute_group*to_remove;
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 89cfd73..6a5faad 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
< at >< at > -1758,17 +1758,21 < at >< at > static void raid5_end_read_request(struct bio * bi, int error)
 mdname(conf->mddev),
 (unsigned long long)s,
 bdn);
-}
-else if (test_bit(R5_ReWrite, &sh->dev[i].flags))
-/* Oh, no!!! */
-printk_ratelimited(
-KERN_WARNING
+} else if (test_bit(R5_ReWrite, &sh->dev[i].flags)) {
+ printk_ratelimited(KERN_WARNING
 "md/raid:%s: read error NOT corrected!! "
 "(sector %llu on %s).\n",
 mdname(conf->mddev),
-(unsigned long long)s,
-bdn);
-else if (atomic_read(&rdev->read_errors)
+(unsigned long long)s, bdn);
+if (atomic_inc_return(&rdev->uncorrected_errors)
+ < atomic_read(&(conf->mddev->max_uncorr_read_errors)))
+set_bad = 1;
+else
+printk(KERN_WARNING
+"md/raid:%s: Too much read error not corrected, "
+"failing device %s.\n",
+mdname(conf->mddev), bdn);
+} else if (atomic_read(&rdev->read_errors)
  > conf->max_nr_stripes)
 printk(KERN_WARNING
        "md/raid:%s: Too many read errors, failing device %s.\n",

[PATCH 1/2] md/raid456: When readed error and raid was degraded,it try to set badsector, not ejecting the rdev.

majianpeng — 2012-05-26T02:53:40

In order to prevent the degraded raid from becaming fail,we should first
set badsector instead of ejecting the rdev when read fail.

Signed-off-by: majianpeng <majianpeng< at >gmail.com>
---
 drivers/md/raid5.c |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index d267672..89cfd73 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
< at >< at > -1737,6 +1737,7 < at >< at > static void raid5_end_read_request(struct bio * bi, int error)
 } else {
 const char *bdn = bdevname(rdev->bdev, b);
 int retry = 0;
+int set_bad = 0;
 
 clear_bit(R5_UPTODATE, &sh->dev[i].flags);
 atomic_inc(&rdev->read_errors);
< at >< at > -1748,7 +1749,8 < at >< at > static void raid5_end_read_request(struct bio * bi, int error)
 mdname(conf->mddev),
 (unsigned long long)s,
 bdn);
-else if (conf->mddev->degraded >= conf->max_degraded)
+else if (conf->mddev->degraded >= conf->max_degraded) {
+set_bad = 1;
 printk_ratelimited(
 KERN_WARNING
 "md/raid:%s: read error not correctable "
< at >< at > -1756,6 +1758,7 < at >< at > static void raid5_end_read_request(struct bio * bi, int error)
 mdname(conf->mddev),
 (unsigned long long)s,
 bdn);
+}
 else if (test_bit(R5_ReWrite, &sh->dev[i].flags))
 /* Oh, no!!! */
 printk_ratelimited(
< at >< at > -1777,7 +1780,10 < at >< at > static void raid5_end_read_request(struct bio * bi, int error)
 else {
 clear_bit(R5_ReadError, &sh->dev[i].flags);
 clear_bit(R5_ReWrite, &sh->dev[i].flags);
-md_error(conf->mddev, rdev);
+if (!(set_bad && test_bit(In_sync, &rdev->flags)
+&& rdev_set_badblocks(rdev,
+sh->sector, STRIPE_SECTORS, 0)))
+md_error(conf->mddev, rdev);
 }
 }
 rdev_dec_pending(rdev, conf->mddev);

[PATCH 0/2] Modify read error handle for RAID-4,5,6.

majianpeng — 2012-05-26T02:52:50

When RAID-4,5,6 degraded and met read-error, it will eject the rdev.And then
the RAID will fail and lost data.Because the function of set-badsector,when 
this occur,it will set-badsector,not ejecting the rdev.
When RAID-4,5,6 met read-error, it will re-write if RAID was not degrade.But if 
re-write error,it will eject the rdev and RAID will degrade and it will take too
long time for recoverying.So I add judgement for controling how may re-write-error
can eject the rdev.

I do those for flexible controling the read-error for different situation.


majianpeng (2):
  md/raid456: When readed error and raid was degraded,it try to
    set badsector, not ejecting the rdev.
  md/raid456:Add interface for contorling eject rdev when re-write
    failed.

 drivers/md/md.c    |   35 +++++++++++++++++++++++++++++++++++
 drivers/md/md.h    |    2 ++
 drivers/md/raid5.c |   28 +++++++++++++++++++---------
 3 files changed, 56 insertions(+), 9 deletions(-)

The $1,549 per day ZERO traffic system (UPDATE) Recommends Advanced Sports to you

2012-05-26T01:51:45

Email        :sniperxsystem< at >support.com
Friend Name  :Friend
Friend Email :linux-raid< at >vger.kernel.org
comment      :

Listen to this... pretty crazy...

So many people rushed to download this 
$530k/year system yesterday...

That they crashed the ENTIRE server!

=>>http://www.sniperxsystem.com/?code=4fbea9cb964f6<<=

(The site was down ALL day) Pretty crazy. 

... The "ghetto" video alone has sent shockwaves 
through the Clickbank community.

Can you believe THIS guy's one of Clickbanks
biggest super affiliates?

=>>http://www.sniperxsystem.com/?code=4fbea9cb964f6<<=

Talk soon

P.S. This is **BRAND NEW**...

It works and it's made $1,549.87 a DAY for 
the past 739 days in a ROW!

No PPC, no PPV, no CPA, no so-called 'push
button softwares' scams, no 'loopholes'...

Something TOTALLY different.

Check it out (fast, while it's still open):

=>>http://www.sniperxsystem.com/?code=4fbea9cb964f6<<=




--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Friend,Could you "build-up" your own energy? Recommends Advanced Sports to you

2012-05-25T18:57:35

Email        :danniel< at >gmail.com
Friend Name  :Friend
Friend Email :linux-raid< at >vger.kernel.org
comment      :


Hi Friend,

I'm sure you already found out the rumours that some
people make their own energy.
Some of them slash the energy bill by half.
Some of them cut the bill completely.
Some even make the electric company pay them(!).
That's why I was ecstatic when I found this website:

http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 

I read every single word, and boy... this stuff really
got me all curious. It seems it's actually very easy 
and cheap to build and use a renewable energy system.

Anyway, I went ahead and bought their package.
I couldn't resisted... It sounds too good to be true,
yet if this turns out to be "real", then this is BIG.

I'm so enthusiasted about this, that I thought to just
send you a link so you get to see it for yourself:

http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 

To a better life,

Danniel Guedotte

PS: Friend, they give a 60-day guarantee. 
You risk nothing. 
But if you snooze, you lose...

http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 




--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tercume edilecek metinleriniz hakkinda

2012-05-23T13:14:21

Sayin ilgili,
 
Biz 10 yili askin bir süredir internet üzerinden profesyonel olarak
CEVIRI / TERCUME HIZMETLERI veren bir kurulusuz. Kurulusumuzun 10. yili  
serefine firmalara ozel, sayfasi 12 TL+KDV'lik bir kampanya hazirladik.

Sadece INGILIZCE - TURKCE ve TURKCE - INGILIZCE cevirilerde gecerli olan ve 
kisa bir sure 
devam edecek bu cazip fiyat avantajindan yararlanmak icin
lutfen bizi hemen simdi arayiniz veya bir e-posta gonderiniz. Diger diller 
icin lutfen fiyat sorunuz.

Not: 1 sayfa = 1000 karakter veya 180 kelimelik dunya standardi 
esas alinmistir. Teknik metinlerde %25 fark alinacaktir. Diger diller icin 
lutfen fiyat aliniz.

Saygilarimizla,
 
Levent Turer,  
Genel Koordinator
Turer Ceviri Hizmetleri

e-posta: info< at >turerceviri.com 
web: www.turerceviri.com 
Tel: 0232 421 13 60
Faks: 0232 421 13 32

Bu e-mail size otomatik olarak, yani bir reklam amaciyla rastgele 
gonderilmemistir.  Eger bizden bu veya benzeri bir konuda 
bir daha e-posta almak istemiyorsaniz, lutfen bize bildiriniz. Size 
rahatsizlik 
verdiysek ozurlerimizi sunariz...

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Friend,Could you "build-up" your own energy? Recommends Advanced Sports to you

2012-05-25T15:37:45

Email        :danniel< at >gmail.com
Friend Name  :Friend
Friend Email :linux-raid< at >vger.kernel.org
comment      :


Hi Friend,

I'm sure you already found out the rumours that some
people make their own energy.
Some of them slash the energy bill by half.
Some of them cut the bill completely.
Some even make the electric company pay them(!).
That's why I was ecstatic when I found this website:

http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 

I read every single word, and boy... this stuff really
got me all curious. It seems it's actually very easy 
and cheap to build and use a renewable energy system.

Anyway, I went ahead and bought their package.
I couldn't resisted... It sounds too good to be true,
yet if this turns out to be "real", then this is BIG.

I'm so enthusiasted about this, that I thought to just
send you a link so you get to see it for yourself:

http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 

To a better life,

Danniel Guedotte

PS: Friend, they give a 60-day guarantee. 
You risk nothing. 
But if you snooze, you lose...

http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 




--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] More test suite enchancements

2012-05-25T15:24:04

From: Jes Sorensen <Jes.Sorensen< at >redhat.com>

Hi,

Here's another set of test suite enhancements. In particular I have
added --logdir and --save-logs, plus --no-error  which allows for one
to run all the tests, without stopping after the first error. This
makes it easier to run the test suite in an automated fashion and
getting a report of all the tests that may have failed. I also did a
bit to make the --help output more useful.

Cheers,
Jes

Jes Sorensen (4):
  Add support for saving log files in test script
  Add --no-error argument to 'test'
  Improve --help message from test
  Move setup code to a function and introduce matching cleanup argument

 test |  113 ++++++++++++++++++++++++++++++++++++++++++++++++------------------
 1 files changed, 82 insertions(+), 31 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] imsm: fix: correct checking volume's degradation

Lukasz Dorau — 2012-05-25T13:06:41

We do not check the return value of sysfs_get_ll() now. It is wrong.
If reading of the sysfs "degraded" key does not succeed,
the "new_degraded" variable will not be initiated
and accidentally it can have the value of "degraded" variable.
In that case the change of degradation will not be checked.

It happens if mdadm is compiled with gcc's "-fstack-protector" option
when one tries to stop a volume under reshape (e.g. OLCE).
Reshape seems to be finished then (metadata is in normal/clean state)
but it is not finished, it is broken and data are corrupted.

Now we always check the return value of sysfs_get_ll().
Even if reading of the sysfs "degraded" key does not succeed
(rv == -1) the change of degradation will be checked.

Signed-off-by: Lukasz Dorau <lukasz.dorau< at >intel.com>
---
 super-intel.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/super-intel.c b/super-intel.c
index 6c87e20..07ab9ae 100644
--- a/super-intel.c
+++ b/super-intel.c
< at >< at > -10370,8 +10370,10 < at >< at > int check_degradation_change(struct mdinfo *info,
      int degraded)
 {
 unsigned long long new_degraded;
-sysfs_get_ll(info, NULL, "degraded", &new_degraded);
-if (new_degraded != (unsigned long long)degraded) {
+int rv;
+
+rv = sysfs_get_ll(info, NULL, "degraded", &new_degraded);
+if ((rv == -1) || (new_degraded != (unsigned long long)degraded)) {
 /* check each device to ensure it is still working */
 struct mdinfo *sd;
 new_degraded = 0;

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mdadm: Fix Segmentation fault.

majianpeng — 2012-05-25T11:49:40

In function write_init_super1():
If "rv = store_super1(st, di->fd)" return error and the di is the last.
Then the di = NULL && rv > 0, so exec:
if (rv)
    fprintf(stderr, Name ": Failed to write metadata to%s\n",
      di->devname);
will be segmentation fault.

Signed-off-by: majianpeng <majianpeng< at >gmail.com>
---
 super1.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/super1.c b/super1.c
index 4f20cc3..37b7a90 100644
--- a/super1.c
+++ b/super1.c
< at >< at > -1242,6 +1242,8 < at >< at > static int write_init_super1(struct supertype *st)
 rv = st->ss->write_bitmap(st, di->fd);
 close(di->fd);
 di->fd = -1;
+if (rv)
+goto error_out;
 }
 error_out:
 if (rv)

very slow file deletion on an SSD

Joe Landman — 2012-05-25T10:37:05

Hi folks:

   Just ran into this (see posted output at bottom).  3.2.14 kernel, MD 
RAID 5, xfs file system.  Not sure (precisely) where the problem is, 
hence posting to both lists.

  [root< at >siFlash ~]# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md22 : active raid5 sdl[0] sds[7] sdx[6] sdu[5] sdk[4] sdz[3] sdw[2] sdr[1]
       1641009216 blocks super 1.2 level 5, 32k chunk, algorithm 2 [8/8] 
[UUUUUUUU]

md20 : active raid5 sdh[0] sdf[7] sdm[6] sdd[5] sdc[4] sde[3] sdi[2] sdg[1]
       1641009216 blocks super 1.2 level 5, 32k chunk, algorithm 2 [8/8] 
[UUUUUUUU]

md21 : active raid5 sdy[0] sdq[7] sdp[6] sdo[5] sdn[4] sdj[3] sdv[2] sdt[1]
       1641009216 blocks super 1.2 level 5, 32k chunk, algorithm 2 [8/8] 
[UUUUUUUU]

md0 : active raid1 sdb1[1] sda1[0]
       93775800 blocks super 1.0 [2/2] [UU]
       bitmap: 1/1 pages [4KB], 65536KB chunk


md2* are SSD RAID5 arrays we are experimenting with.  Xfs file systems 
atop them:

[root< at >siFlash ~]# mount | grep md2
/dev/md20 on /data/1 type xfs (rw)
/dev/md21 on /data/2 type xfs (rw)
/dev/md22 on /data/3 type xfs (rw)

vanilla mount options (following Dave Chinner's long standing advice)

meta-data=/dev/md20              isize=2048   agcount=32, 
agsize=12820392 blks
          =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=410252304, imaxpct=5
          =                       sunit=8      swidth=56 blks
naming   =version 2              bsize=65536  ascii-ci=0
log      =internal               bsize=4096   blocks=30720, version=2
          =                       sectsz=512   sunit=8 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

[root< at >siFlash ~]# mdadm --detail /dev/md20
/dev/md20:
         Version : 1.2
   Creation Time : Sun Apr  1 19:36:39 2012
      Raid Level : raid5
      Array Size : 1641009216 (1564.99 GiB 1680.39 GB)
   Used Dev Size : 234429888 (223.57 GiB 240.06 GB)
    Raid Devices : 8
   Total Devices : 8
     Persistence : Superblock is persistent

     Update Time : Fri May 25 06:26:23 2012
           State : clean
  Active Devices : 8
Working Devices : 8
  Failed Devices : 0
   Spare Devices : 0

          Layout : left-symmetric
      Chunk Size : 32K

            Name : siFlash.sicluster:20
            UUID : 2f023323:6ec29eb9:a943de06:f6e0c25d
          Events : 296

     Number   Major   Minor   RaidDevice State
        0       8      112        0      active sync   /dev/sdh
        1       8       96        1      active sync   /dev/sdg
        2       8      128        2      active sync   /dev/sdi
        3       8       64        3      active sync   /dev/sde
        4       8       32        4      active sync   /dev/sdc
        5       8       48        5      active sync   /dev/sdd
        6       8      192        6      active sync   /dev/sdm
        7       8       80        7      active sync   /dev/sdf

All the SSDs are on deadline scheduler

[root< at >siFlash ~]# cat /sys/block/sd*/queue/scheduler | uniq
noop [deadline] cfq


All this said, deletes from this unit are taking 1-2 seconds per file ...

[root< at >siFlash ~]# strace -ttt -T rm -f /data/2/test/*
1337941514.040788 execve("/bin/rm", ["rm", "-f", 
"/data/2/test/2.8t-r.97.0", "/data/2/test/2.8t-r.98.0", 
"/data/2/test/2.8t-r.99.0", "/data/2/test/2.9.0"], [/* 40 vars */]) = 0 
<0.000552>
1337941514.041713 brk(0)                = 0x60d000 <0.000031>
1337941514.041927 mmap(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7bc2779000 <0.000032>
1337941514.042113 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No 
such file or directory) <0.000109>
1337941514.042395 open("/etc/ld.so.cache", O_RDONLY) = 3 <0.000050>
1337941514.042614 fstat(3, {st_mode=S_IFREG|0644, st_size=81118, ...}) = 
0 <0.000102>
1337941514.042928 mmap(NULL, 81118, PROT_READ, MAP_PRIVATE, 3, 0) = 
0x7f7bc2765000 <0.000042>
1337941514.043078 close(3)              = 0 <0.000019>
1337941514.043235 open("/lib64/libc.so.6", O_RDONLY) = 3 <0.000115>
1337941514.043477 read(3, 
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\355\301W4\0\0\0"..., 
832) = 832 <0.000039>
1337941514.043647 fstat(3, {st_mode=S_IFREG|0755, st_size=1908792, ...}) 
= 0 <0.000020>
1337941514.043860 mmap(0x3457c00000, 3733672, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3457c00000 <0.000085>
1337941514.044065 mprotect(0x3457d86000, 2097152, PROT_NONE) = 0 <0.000034>
1337941514.044191 mmap(0x3457f86000, 20480, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x186000) = 0x3457f86000 <0.000034>
1337941514.044388 mmap(0x3457f8b000, 18600, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3457f8b000 <0.000085>
1337941514.044592 close(3)              = 0 <0.000058>
1337941514.044763 mmap(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7bc2764000 <0.000039>
1337941514.044893 mmap(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7bc2763000 <0.000020>
1337941514.044981 mmap(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7bc2762000 <0.000018>
1337941514.045076 arch_prctl(ARCH_SET_FS, 0x7f7bc2763700) = 0 <0.000018>
1337941514.045183 mprotect(0x3457f86000, 16384, PROT_READ) = 0 <0.000023>
1337941514.045270 mprotect(0x345761f000, 4096, PROT_READ) = 0 <0.000019>
1337941514.045350 munmap(0x7f7bc2765000, 81118) = 0 <0.000028>
1337941514.045619 brk(0)                = 0x60d000 <0.000017>
1337941514.045698 brk(0x62e000)         = 0x62e000 <0.000018>
1337941514.045803 open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 
<0.000028>
1337941514.045904 fstat(3, {st_mode=S_IFREG|0644, st_size=99158704, 
...}) = 0 <0.000017>
1337941514.046012 mmap(NULL, 99158704, PROT_READ, MAP_PRIVATE, 3, 0) = 
0x7f7bbc8d1000 <0.000020>
1337941514.046099 close(3)              = 0 <0.000017>
1337941514.046235 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost 
isig icanon echo ...}) = 0 <0.000020>
1337941514.046373 newfstatat(AT_FDCWD, "/data/2/test/2.8t-r.97.0", 
{st_mode=S_IFREG|0600, st_size=1073741824, ...}, AT_SYMLINK_NOFOLLOW) = 
0 <0.000024>
1337941514.046504 unlinkat(AT_FDCWD, "/data/2/test/2.8t-r.97.0", 0) = 0 
<1.357571>
1337941515.404257 newfstatat(AT_FDCWD, "/data/2/test/2.8t-r.98.0", 
{st_mode=S_IFREG|0600, st_size=1073741824, ...}, AT_SYMLINK_NOFOLLOW) = 
0 <0.000072>
1337941515.404485 unlinkat(AT_FDCWD, "/data/2/test/2.8t-r.98.0", 0) = 0 
<1.608016>
1337941517.012706 newfstatat(AT_FDCWD, "/data/2/test/2.8t-r.99.0", 
{st_mode=S_IFREG|0600, st_size=1073741824, ...}, AT_SYMLINK_NOFOLLOW) = 
0 <0.000082>
1337941517.012957 unlinkat(AT_FDCWD, "/data/2/test/2.8t-r.99.0", 0) = 0 
<1.133890>
1337941518.146983 newfstatat(AT_FDCWD, "/data/2/test/2.9.0", 
{st_mode=S_IFREG|0600, st_size=8589934592, ...}, AT_SYMLINK_NOFOLLOW) = 
0 <0.000023>
1337941518.147145 unlinkat(AT_FDCWD, "/data/2/test/2.9.0", 0) = 0 <0.938754>
1337941519.086125 close(0)              = 0 <0.000102>
1337941519.086357 close(1)              = 0 <0.000061>
1337941519.086540 close(2)              = 0 <0.000021>
1337941519.086694 exit_group(0)         = ?

Anything obvious that we are doing wrong?


Machine may be occupied for a bit.  Might be a few days before we can 
get results back.

The $1,549 per day ZERO traffic system (UPDATE) Recommends Advanced Sports to you

2012-05-25T01:33:02

Email        :sniperxsystem< at >support.com
Friend Name  :Friend
Friend Email :linux-raid< at >vger.kernel.org
comment      :

Listen to this... pretty crazy...

So many people rushed to download this 
$530k/year system yesterday...

That they crashed the ENTIRE server!

=>>http://www.sniperxsystem.com/?code=4fbea9cb964f6<<=

(The site was down ALL day) Pretty crazy. 

... The "ghetto" video alone has sent shockwaves 
through the Clickbank community.

Can you believe THIS guy's one of Clickbanks
biggest super affiliates?

=>>http://www.sniperxsystem.com/?code=4fbea9cb964f6<<=

Talk soon

P.S. This is **BRAND NEW**...

It works and it's made $1,549.87 a DAY for 
the past 739 days in a ROW!

No PPC, no PPV, no CPA, no so-called 'push
button softwares' scams, no 'loopholes'...

Something TOTALLY different.

Check it out (fast, while it's still open):

=>>http://www.sniperxsystem.com/?code=4fbea9cb964f6<<=




--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi! Is "container" more efficient in terms of I/O op. numbers ...

Igor Podlesny — 2012-05-24T15:30:54

   ... then several "stand-alone" RAIDs on the same HDDs? -- Say, when
using write intent bitmaps.

Activate your free commission shop now Recommends Advanced Sports to you

2012-05-24T12:00:05

Email        :kimtan< at >gmail.com
Friend Name  :Friend
Friend Email :linux-raid< at >vger.kernel.org
comment      :

Hey,

Your commission shop is ready.
Activate your free commission shop now:

==> http://bit.ly/KUXNMS

In a few minutes, your commission shop will be ready, 
attracting buyers from all around the world.

And each shop is designed to suck commissions and sales 
for you automatically. 

This is the first time this revolutionary technique is applied.

So don't delay. Activate your commission shop now:

==> http://bit.ly/KUXNMS

Sincerely,
Kim Tan



--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Activate your free commission shop now Recommends Advanced Sports to you

2012-05-24T06:03:16

Email        :kimtan< at >gmail.com
Friend Name  :Friend
Friend Email :linux-raid< at >vger.kernel.org
comment      :

Hey,

Your commission shop is ready.
Activate your free commission shop now:

==> http://bit.ly/KUXNMS

In a few minutes, your commission shop will be ready, 
attracting buyers from all around the world.

And each shop is designed to suck commissions and sales 
for you automatically. 

This is the first time this revolutionary technique is applied.

So don't delay. Activate your commission shop now:

==> http://bit.ly/KUXNMS

Sincerely,
Kim Tan



--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Increase minimum chunk size in testsuite to 64kB

Anton Blanchard — 2012-05-24T05:10:47

When running the mdadm testsuite on ppc64 with a 64kB page size I
see a couple of failures because the chunk size is smaller than a
page.

Bump the chunksize to 64kB to fix these failures.

Signed-off-by: Anton Blanchard <anton< at >samba.org>
---

diff --git a/tests/02r5grow b/tests/02r5grow
index f9fd571..b91ffcd 100644
--- a/tests/02r5grow
+++ b/tests/02r5grow
< at >< at > -2,7 +2,7 < at >< at >
 
 # create a small raid5 array, make it larger.  Then make it smaller
 
-mdadm -CR $md0 -e0.90 --level raid5 --chunk=32 --raid-disks 3 --size $[size/2] $dev1 $dev2 $dev3 
+mdadm -CR $md0 -e0.90 --level raid5 --chunk=64 --raid-disks 3 --size $[size/2] $dev1 $dev2 $dev3 
 check wait
 check state UUU
 testdev $md0 2 $[size/2] 32
diff --git a/tests/02r6grow b/tests/02r6grow
index 3f53904..38c7781 100644
--- a/tests/02r6grow
+++ b/tests/02r6grow
< at >< at > -2,7 +2,7 < at >< at >
 
 # create a small raid6 array, make it larger.  Then make it smaller
 
-mdadm -CR $md0 -e 0.90 --level raid6 --chunk=32 --raid-disks 4 --size $[size/2] $dev1 $dev2 $dev3 $dev4 
+mdadm -CR $md0 -e 0.90 --level raid6 --chunk=64 --raid-disks 4 --size $[size/2] $dev1 $dev2 $dev3 $dev4 
 check wait
 check state UUUU
 testdev $md0 2 $[size/2] 32
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] lib/raid6: fix sparse warnings in recovery functions

Jim Kukunas — 2012-05-24T04:54:18

Make the recovery functions static to fix the following sparse warnings:

lib/raid6/recov.c:25:6: warning: symbol 'raid6_2data_recov_intx1' was
not declared. Should it be static?
lib/raid6/recov.c:69:6: warning: symbol 'raid6_datap_recov_intx1' was
not declared. Should it be static?
lib/raid6/recov_ssse3.c:22:6: warning: symbol 'raid6_2data_recov_ssse3'
was not declared. Should it be static?
lib/raid6/recov_ssse3.c:197:6: warning: symbol 'raid6_datap_recov_ssse3'
was not declared. Should it be static?

Reported-by: Fengguang Wu <fengguang.wu< at >intel.com>
Signed-off-by: Jim Kukunas <james.t.kukunas< at >linux.intel.com>
---
 lib/raid6/recov.c       |    7 ++++---
 lib/raid6/recov_ssse3.c |    7 ++++---
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/raid6/recov.c b/lib/raid6/recov.c
index 1805a5c..a95bccb 100644
--- a/lib/raid6/recov.c
+++ b/lib/raid6/recov.c
< at >< at > -22,8 +22,8 < at >< at >
 #include <linux/raid/pq.h>
 
 /* Recover two failed data blocks. */
-void raid6_2data_recov_intx1(int disks, size_t bytes, int faila, int failb,
-       void **ptrs)
+static void raid6_2data_recov_intx1(int disks, size_t bytes, int faila,
+int failb, void **ptrs)
 {
 u8 *p, *q, *dp, *dq;
 u8 px, qx, db;
< at >< at > -66,7 +66,8 < at >< at > void raid6_2data_recov_intx1(int disks, size_t bytes, int faila, int failb,
 }
 
 /* Recover failure of one data block plus the P block */
-void raid6_datap_recov_intx1(int disks, size_t bytes, int faila, void **ptrs)
+static void raid6_datap_recov_intx1(int disks, size_t bytes, int faila,
+void **ptrs)
 {
 u8 *p, *q, *dq;
 const u8 *qmul;/* Q multiplier table */
diff --git a/lib/raid6/recov_ssse3.c b/lib/raid6/recov_ssse3.c
index b77266f..ecb0289 100644
--- a/lib/raid6/recov_ssse3.c
+++ b/lib/raid6/recov_ssse3.c
< at >< at > -19,8 +19,8 < at >< at > static int raid6_has_ssse3(void)
 boot_cpu_has(X86_FEATURE_SSSE3);
 }
 
-void raid6_2data_recov_ssse3(int disks, size_t bytes, int faila, int failb,
-       void **ptrs)
+static void raid6_2data_recov_ssse3(int disks, size_t bytes, int faila,
+int failb, void **ptrs)
 {
 u8 *p, *q, *dp, *dq;
 const u8 *pbmul;/* P multiplier table for B data */
< at >< at > -194,7 +194,8 < at >< at > void raid6_2data_recov_ssse3(int disks, size_t bytes, int faila, int failb,
 }
 
 
-void raid6_datap_recov_ssse3(int disks, size_t bytes, int faila, void **ptrs)
+static void raid6_datap_recov_ssse3(int disks, size_t bytes, int faila,
+void **ptrs)
 {
 u8 *p, *q, *dq;
 const u8 *qmul;/* Q multiplier table */

[Training] Here's how to profit $600 a day Recommends Advanced Sports to you

2012-05-23T20:14:05

Email        :christian< at >aol.com
Friend Name  :Friend
Friend Email :linux-raid< at >vger.kernel.org
comment      :

Hey,

I've got a treat for you today.

You're about to receive INSTANT
ACCESS to some free training on
how you can profit up to $600 a day

=> http://www.bank-blogging.com/?code=4fbce89b05ddc 


There is no cost. 

Talk Soon,

Christian



=> http://www.bank-blogging.com/?code=4fbce89b05ddc 



--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Sequential writing to degraded RAID6 causing a lot of reading

Patrik Horník — 2012-05-23T19:01:09

Hello boys,

I am running some RAID6 arrays in degraded mode, one with
left-symmetry layout and one with left-symmetry-6 layout. I am
experiencing (potentially strange) behavior that degrades performance
of both arrays.

When I am writing sequentially a lot of data to healthy RAID5 array,
it also reads internally a bit of data. I have data on arrays, so I
only write through the filesystem. So I am not sure what causing the
reads, if writing through filesystem potentially causes skipping and
not writing whole stripes  or sometimes timing causes that the whole
stripe is not written at the same time. But anyway there is only a
small ratio of reads and the performance is almost OK.

I cant test it with full healthy RAID6 array, because I dont have any
at the moment.

But when I write sequentially to RAID6 without one drive (again
through filesystem) I get almost exactly the same amount of internal
reads as writes. Is it by design and is this expected behaviour? Why
does it behave like this? It should behave exactly like healthy RAID5,
it should detect the writing of whole stripe and should not read
(almost) anything.

Thanks.

Patrik
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Training] Here's how to profit $600 a day Recommends Advanced Sports to you

2012-05-23T16:36:31

Email        :christian< at >aol.com
Friend Name  :Friend
Friend Email :linux-raid< at >vger.kernel.org
comment      :

Hey,

I've got a treat for you today.

You're about to receive INSTANT
ACCESS to some free training on
how you can profit up to $600 a day

=> http://www.bank-blogging.com/?code=4fbce89b05ddc 


There is no cost. 

Talk Soon,

Christian



=> http://www.bank-blogging.com/?code=4fbce89b05ddc 



--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] md/raid456:Remove the judgement atomic_read(&rdev->read_errors).

majianpeng — 2012-05-23T12:38:16

It isn't necessary to judge.Because the atomic_read and atomic_set is excuce same cpu. So
read_errors is zero or not, directly set it zero.
Signed-off-by: majianpeng <majianpeng< at >gmail.com>
---
 drivers/md/raid5.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index f351422..1fe2def 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
< at >< at > -1690,8 +1690,7 < at >< at > static void raid5_end_read_request(struct bio * bi, int error)
 clear_bit(R5_ReadError, &sh->dev[i].flags);
 clear_bit(R5_ReWrite, &sh->dev[i].flags);
 }
-if (atomic_read(&rdev->read_errors))
-atomic_set(&rdev->read_errors, 0);
+atomic_set(&rdev->read_errors, 0);
 } else {
 const char *bdn = bdevname(rdev->bdev, b);
 int retry = 0;