I had an interesting problem earlier today. While running r1soft backup, dmesg was throwing some I\/O like the following:<\/p>\n
Dec 28 09:28:43 ssd1 kernel: [36701.752626] end_request: I\/O error, dev vda, sector 331781632
\nDec 28 09:28:43 ssd1 kernel: [36701.755400] end_request: I\/O error, dev vda, sector 331781760
\nDec 28 09:28:43 ssd1 kernel: [36701.758286] end_request: I\/O error, dev vda, sector 331781888
\nDec 28 09:28:43 ssd1 kernel: [36701.760992] end_request: I\/O error, dev vda, sector 331780864<\/p><\/blockquote>\nThey didn’t go out after multiple file system checks. That left me no choice other than finding what’s actually in that sector. I could see the sector numbers was increasing by 128 up 10 sequential logs. That makes to understand it could be a specific account causing the errors.<\/p>\n
EXT file system comes with an interesting tool called debugfs. This can be used on mounted file system and can be used to track down IO related issues. Although, you require to do some calculation first to convert sector to block number of a specific partition before you can use debugfs.<\/p>\n
The lowest sector number in the log was ‘331780864’. First I tracked down the partition where this sector lies. This can be done using fdisk -lu \/dev\/disk (Make sure to use -u, to ensure fdisk returns the sector numbers instead of cylinder number)<\/p>\n
#fdisk -lu \/dev\/vda<\/p>\n
Disk \/dev\/vda: 1342.2 GB, 1342177280000 bytes
\n16 heads, 63 sectors\/track, 2600634 cylinders, total 2621440000 sectors
\nUnits = sectors of 1 * 512 = 512 bytes
\nSector size (logical\/physical): 512 bytes \/ 512 bytes
\nI\/O size (minimum\/optimal): 512 bytes \/ 512 bytes
\nDisk identifier: 0x0002f013<\/p>\nDevice Boot Start End Blocks Id System
\n\/dev\/vda1 * 2048 411647 204800 83 Linux
\n\/dev\/vda2 411648 205211647 102400000 83 Linux
\n\/dev\/vda3 205211648 209307647 2048000 82 Linux swap \/ Solaris
\n\/dev\/vda4 209307648 2621439999 1206066176 83 Linux<\/p><\/blockquote>\nNow, find the Start Number < Our Sector number to detect which block contains our desired sector. In our case, it is \/dev\/vda4. Once done, we need to numeric sector number specifically for this partition, which can be done by subtracting our sector number with start number of the partition. In our case:<\/p>\n
331780864 –\u00a0209307648 =\u00a0122473216<\/p><\/blockquote>\n
That means, our sector lies in\u00a0122473216th sector of \/dev\/vda4.<\/p>\n
Now find the block size by tune2fs:<\/p>\n
# tune2fs -l \/dev\/vda4 | grep Block
\nBlock count: 301516544
\nBlock size: 4096
\nBlocks per group: 32768<\/p><\/blockquote>\nIn our case, it is 4096.<\/p>\n
Now determine the size of the sectors by bytes. This is shown in fdisk output:<\/p>\n
Sector size (logical\/physical): 512 bytes \/ 512 bytes<\/p><\/blockquote>\n
From the two relations block\/bytes and sector\/bytes, find sector\/block : 512 \/ 4096 = .125<\/p>\n
Now, calculate the block number of\u00a0122473216th sector:\u00a0122473216 x .125 =\u00a015309152<\/p>\n
We can now use debugfs to determine what file we have on that block number as following:<\/p>\n
debugfs \/dev\/vda4<\/p><\/blockquote>\n
On the debug prompt, type:<\/p>\n
debugfs: icheck\u00a015309152<\/p>\n
Block\u00a0\u00a0 Inode number
\n15309152\u00a0 \u00a02611435<\/em><\/p><\/blockquote>\nThis will show the inode number of the desired file. Use the inode number to run:<\/p>\n
debugfs: ncheck 15309152<\/p>\n
Inode\u00a0\u00a0 Pathname
\n15309152 \/lost+found\/#29938847<\/p><\/blockquote>\nThis will show you the desired file that is actually causing the issue. In my case, I could find files that were corrupted in some old fsck, were stored in lost+found and they were missing magic number\/incomplete files. Once I had deleted all the files from lost+found, my issue was resolved. Viola!<\/p>\n","protected":false},"excerpt":{"rendered":"
I had an interesting problem earlier today. While running r1soft backup, dmesg was throwing some I\/O like the following: Dec 28 09:28:43 ssd1 kernel: [36701.752626] end_request: I\/O error, dev vda, sector 331781632 Dec 28 09:28:43 ssd1 kernel: [36701.755400] end_request: I\/O error, dev vda, sector 331781760 Dec 28 09:28:43 ssd1 kernel: [36701.758286] end_request: I\/O error, dev … Continue reading “Identifying File \/ Inode by Sector \/ Block Number in Linux”<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[169,12,20,21,150,25],"tags":[172,171,170],"_links":{"self":[{"href":"https:\/\/mellowhost.com\/blog\/wp-json\/wp\/v2\/posts\/354"}],"collection":[{"href":"https:\/\/mellowhost.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mellowhost.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mellowhost.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/mellowhost.com\/blog\/wp-json\/wp\/v2\/comments?post=354"}],"version-history":[{"count":3,"href":"https:\/\/mellowhost.com\/blog\/wp-json\/wp\/v2\/posts\/354\/revisions"}],"predecessor-version":[{"id":357,"href":"https:\/\/mellowhost.com\/blog\/wp-json\/wp\/v2\/posts\/354\/revisions\/357"}],"wp:attachment":[{"href":"https:\/\/mellowhost.com\/blog\/wp-json\/wp\/v2\/media?parent=354"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mellowhost.com\/blog\/wp-json\/wp\/v2\/categories?post=354"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mellowhost.com\/blog\/wp-json\/wp\/v2\/tags?post=354"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}