linux-ext4 - [Bug 16081] Data loss after crash during heavy I/O

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 2 Jun 2010 21:57:00 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 16081] Data loss after crash during heavy I/O

https://bugzilla.kernel.org/show_bug.cgi?id=16081





--- Comment #13 from lkolbe@...hfak.uni-bielefeld.de  2010-06-02 21:56:56 ---
Funny thing is, dm-6 is the root-filesystem, and it's 4GB big. It lives on a VG
consisting of one 100GB RAID-50 over 24 disks. Some relevant data:

shepherd:~# lvm lvs -a -o+devices
  LV          VG     Attr   LSize   Origin Snap%  Move Log Copy%  Convert
Devices          
  badp1       data   -wi-ao   9.00T                                      
/dev/sdb(25600)  
  badp2       data   -wi-ao   9.00T                                      
/dev/sdb(2384896)
  baspool     data   -wi-ao   1.00T                                      
/dev/sdb(4769792)
  bawork      data   -wi-ao 100.00G                                      
/dev/sdb(0)      
  db1_srv     data   -wi-ao 100.00G                                      
/dev/sdb(4744192)
  dir1_bawork data   -wi-ao 100.00G                                      
/dev/sdb(5031936)
  db1_log     system -wi-ao   4.00G                                      
/dev/sda1(7168)  
  db1_root    system -wi-ao   4.00G                                      
/dev/sda1(6144)  
  db1_swap    system -wi-ao   4.00G                                      
/dev/sda1(8192)  
  dir1_log    system -wi-ao   4.00G                                      
/dev/sda1(4096)  
  dir1_root   system -wi-ao   4.00G                                      
/dev/sda1(3072)  
  dir1_swap   system -wi-ao   4.00G                                      
/dev/sda1(5120)  
  log         system -wi-ao   4.00G                                      
/dev/sda1(1024)  
  root        system -wi-ao   4.00G                                      
/dev/sda1(0)     
  swap        system -wi-ao   4.00G                                      
/dev/sda1(2048)  

The requested dmsetup table:
shepherd:~# dmsetup table
data-dir1_bawork: 0 209715200 linear 8:16 41221620096
system-db1_log: 0 8388608 linear 8:1 58720640
system-db1_swap: 0 8388608 linear 8:1 67109248
system-db1_root: 0 8388608 linear 8:1 50332032
data-bawork: 0 209715200 linear 8:16 384
data-db1_srv: 0 209715200 linear 8:16 38864421248
data-baspool: 0 2147483648 linear 8:16 39074136448
system-dir1_swap: 0 8388608 linear 8:1 41943424
system-dir1_root: 0 8388608 linear 8:1 25166208
data-badp2: 0 19327352832 linear 8:16 19537068416
data-badp1: 0 19327352832 linear 8:16 209715584
system-swap: 0 8388608 linear 8:1 16777600
system-root: 0 8388608 linear 8:1 384
system-dir1_log: 0 8388608 linear 8:1 33554816
system-log 0 8388608 linear 8:1 8388992

Adaptec version numbers are: BIOS, Firmware, Boot flash: 17899
aacraid driver: 2461 (the version shipped with 2.6.32)

I have (yet) no reason not to trust our storage - it's one 100GB RAID-50 and
one ~19TB RAID-50 on 24 Hitachi HDE721010SLA330 with firmware ST6OA3AA, if that
means anything to anyone.

Since the last crash bacula has written 3.2TiB to data-badp1 and it's still
running (when all backups are done, it should have written ~12TiB). We'll see
if it survives tomorrow.

If it crashes again, I'll try 8TiB-Filesystems.

Thanks for taking your time!
Lukas

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html