| 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
| ||
|
Date: Mon, 03 Aug 2009 09:54:36 -0400 From: Nick Dokos <nicholas.dokos@...com> To: linux-ext4@...r.kernel.org Cc: nicholas.dokos@...com Subject: ll_ver_fs data verification failure - 96TB fs Just a heads-up for now. I ran ll_ver_fs on a 96TB fs - the write phase finished without problems, but the read phase encountered a problem: ... read File name: /mnt/dir00373/file026 liverfs: verify /mnt/dir00373/file026 failed offset/timestamp/inode 3244298240/1248819541/1096796: found 3243249664/1248819541/1096796 instead liverfs: Data verification failed 770.45user 218639.65system 67:38:18elapsed 90%CPU (0avgtext+0avgdata 0maxresident)k 100357573552inputs+195522668184outputs (1major+414minor)pagefaults 0swaps make: *** [llver] Error 2 The offset difference is exactly 1M, and it occurs about 3GB into the file. In total, there are 726 directories, each with 32 4GB files (except the last, which only has 12 files). So directory 373 is roughly half-way. I'll take a look at the block allocation of both the directory and the file and see if they are straddling the 16TB boundary (or other such). Running a fsck now to see if there are other problems. Thanks, Nick -- 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
Powered by blists - more mailing lists