October 29, 201015 yr I am unable to write to the Cache drive. I get a permissions error on Windows saying I do not have permission to write. Attached is my syslog. I have partitioned the Cache drive and was using the other partition for Sabnzbd and sickbeard. It was working fine before I made the partition so now I'm thinking I screwed something up. I've noticed in the syslog I have some ReiserFS errors. Tower kernel: REISERFS (device sdb1): found reiserfs format "3.6" with standard journal Oct 28 22:20:51 Tower kernel: REISERFS (device sdb1): using ordered data mode Oct 28 22:20:51 Tower emhttp: shcmd (17): set -o pipefail ; mount -t reiserfs -o noacl,nouser_xattr,noatime,nodiratime /dev/md2 /mnt/disk2 2>&1 | logger Oct 28 22:20:51 Tower kernel: md: recovery thread has nothing to resync Oct 28 22:20:51 Tower kernel: REISERFS (device sdb1): journal params: device sdb1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 28 22:20:51 Tower kernel: REISERFS (device sdb1): checking transaction log (sdb1) Oct 28 22:20:51 Tower kernel: REISERFS (device md3): found reiserfs format "3.6" with standard journal Oct 28 22:20:51 Tower kernel: REISERFS (device md3): using ordered data mode Oct 28 22:20:51 Tower kernel: REISERFS (device md1): found reiserfs format "3.6" with standard journal Oct 28 22:20:51 Tower kernel: REISERFS (device md1): using ordered data mode Oct 28 22:20:51 Tower kernel: REISERFS (device md3): journal params: device md3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 28 22:20:51 Tower kernel: REISERFS (device md3): checking transaction log (md3) Oct 28 22:20:51 Tower kernel: REISERFS (device md1): journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 28 22:20:51 Tower kernel: REISERFS (device md1): checking transaction log (md1) Oct 28 22:20:51 Tower kernel: REISERFS (device sdb1): Using r5 hash to sort names Oct 28 22:20:51 Tower kernel: attempt to access beyond end of device Oct 28 22:20:51 Tower kernel: sdb1: rw=0, want=1331429392, limit=976759686 Oct 28 22:20:51 Tower kernel: REISERFS error (device sdb1): vs-2140 finish_unfinished: search_by_key returned -2 Oct 28 22:20:51 Tower kernel: REISERFS (device sdb1): Remounting filesystem read-only Oct 28 22:20:51 Tower kernel: REISERFS (device md4): found reiserfs format "3.6" with standard journal Oct 28 22:20:51 Tower kernel: REISERFS (device md4): using ordered data mode Oct 28 22:20:51 Tower kernel: REISERFS (device md2): found reiserfs format "3.6" with standard journal Oct 28 22:20:51 Tower kernel: REISERFS (device md2): using ordered data mode Oct 28 22:20:51 Tower kernel: REISERFS (device md4): journal params: device md4, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 28 22:20:51 Tower kernel: REISERFS (device md4): checking transaction log (md4) Oct 28 22:20:51 Tower kernel: REISERFS (device md2): journal params: device md2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 28 22:20:51 Tower kernel: REISERFS (device md2): checking transaction log (md2) Oct 28 22:20:51 Tower kernel: REISERFS (device md3): Using r5 hash to sort names Oct 28 22:20:51 Tower kernel: REISERFS (device md1): Using r5 hash to sort names Oct 28 22:20:51 Tower kernel: REISERFS (device md4): Using r5 hash to sort names Oct 28 22:20:51 Tower kernel: REISERFS (device md2): Using r5 hash to sort names syslog-2010-10-28.txt
October 29, 201015 yr Author ran reiserfsck and got this. root@Tower:~# reiserfsck --check /dev/sdb1 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/sdb1 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes bread: Cannot read the block (244190637): (Invalid argument). reiserfs_open: Your partition is not big enough to contain the filesystem of (244190637) blocks as was specified in the found super block. Failed to open the filesystem. If the partition table has not been changed, and the partition is valid and it really contains a reiserfs partition, then the superblock is corrupted and you need to run this utility with --rebuild-sb.
October 29, 201015 yr ran reiserfsck and got this. root@Tower:~# reiserfsck --check /dev/sdb1 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/sdb1 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes bread: Cannot read the block (244190637): (Invalid argument). reiserfs_open: Your partition is not big enough to contain the filesystem of (244190637) blocks as was specified in the found super block. Failed to open the filesystem. If the partition table has not been changed, and the partition is valid and it really contains a reiserfs partition, then the superblock is corrupted and you need to run this utility with --rebuild-sb. Do you have a gigabyte motherboard? The last time I saw the error you are getting the drive had an HPA added by the BIOS after the file-system had been created. As the reiserfsck command output said, before doing anything else need to verify the partitioning. We need to see the output of fdisk -l /dev/sdb and hdparm -N /dev/sdb Joe L. Joe L.
October 29, 201015 yr Author Do you have a gigabyte motherboard? The last time I saw the error you are getting the drive had an HPA added by the BIOS after the file-system had been created. As the reiserfsck command output said, before doing anything else need to verify the partitioning. We need to see the output of fdisk -l /dev/sdb and hdparm -N /dev/sdb Joe L. Joe L. I do have a Gigabyte board. It is weird since the HPA is disabled by default. When I installed this drive and the other drives on my tower, I've made sure to check BIOS to verify that it is off. root@Tower:~# fdisk -l /dev/sdb Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes 1 heads, 63 sectors/track, 31008336 cylinders Units = cylinders of 63 * 512 = 32256 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdb1 2 15504123 488379843 83 Linux /dev/sdb2 15504124 31008336 488382709+ 83 Linux root@Tower:~# hdparm -N /dev/sdb /dev/sdb: max sectors = 1953525168/7368112, HPA setting seems invalid root@Tower:~# Looks like HPA is on the drive. Will deleting the partition and re doing it help to get rid of the HPA? The first partition is the cache drive. The other I was using to run SABnzbd and sickbeard. So I do not have any other important data on it. I can always install sab again.
October 29, 201015 yr root@Tower:~# hdparm -N /dev/sdb /dev/sdb: max sectors = 1953525168/7368112, HPA setting seems invalid root@Tower:~# Looks like HPA is on the drive. Will deleting the partition and re doing it help to get rid of the HPA? The first partition is the cache drive. The other I was using to run SABnzbd and sickbeard. So I do not have any other important data on it. I can always install sab again. No, deleting the partition will not do it. The drive thinks it is now smaller. A LOT smaller. The HPA is using ALL but 3,772,473,344 bytes ( 3.77 Gig ) You'll need to first remove the HPA, then fix the partition table, then go from there. You might be able to remove the HPA by typing: hdparm -N p1953525168 /dev/sdb Only one operation changing the HPA is allowed per power cycle, so it might not work if your BIOS already attempted it since power up. Joe L.
October 29, 201015 yr Author didn't work. and it seems that all my drives have HPA on them Tower login: root Linux 2.6.32.9-unRAID. root@Tower:~# hdparm -N p1953525168 /dev/sdb /dev/sdb: setting max visible sectors to 1953525168 (permanent) max sectors = 1953525168/7368112, HPA setting seems invalid root@Tower:~# hdparm -N /dev/sdd /dev/sdd: max sectors = 18446744073321613488/14715056, HPA setting seems invalid root@Tower:~# hdparm -N /dev/sde /dev/sde: max sectors = 18446744073321613488/14715056, HPA setting seems invalid root@Tower:~# hdparm -N /dev/sdf /dev/sdf: max sectors = 18446744073321613488/14715056, HPA setting seems invalid root@Tower:~# hdparm -N /dev/sdg /dev/sdg: max sectors = 18446744073321613488/14715056, HPA setting seems invalid root@Tower:~# hdparm -N /dev/sdc /dev/sdc: max sectors = 18446744073321613488/14715056, HPA setting seems invalid root@Tower:~#
October 30, 201015 yr didn't work. and it seems that all my drives have HPA on them Tower login: root Linux 2.6.32.9-unRAID. root@Tower:~# hdparm -N p1953525168 /dev/sdb /dev/sdb: setting max visible sectors to 1953525168 (permanent) max sectors = 1953525168/7368112, HPA setting seems invalid root@Tower:~# hdparm -N /dev/sdd /dev/sdd: max sectors = 18446744073321613488/14715056, HPA setting seems invalid root@Tower:~# hdparm -N /dev/sde /dev/sde: max sectors = 18446744073321613488/14715056, HPA setting seems invalid root@Tower:~# hdparm -N /dev/sdf /dev/sdf: max sectors = 18446744073321613488/14715056, HPA setting seems invalid root@Tower:~# hdparm -N /dev/sdg /dev/sdg: max sectors = 18446744073321613488/14715056, HPA setting seems invalid root@Tower:~# hdparm -N /dev/sdc /dev/sdc: max sectors = 18446744073321613488/14715056, HPA setting seems invalid root@Tower:~# The others are just mis-reporting the size. There is no way you have 18446744073321613488 sectors... you don't even have that many bytes... 18446744073321613488 bytes 18446744073321613 Kb 18446744073321 Meg 18446744073 Gig 18446744 TB Unless you are from the future, there is no way you have a bunch of 18 Million Terrabyte drives in your server.
October 30, 201015 yr Author The others are just mis-reporting the size. There is no way you have 18446744073321613488 sectors... you don't even have that many bytes... 18446744073321613488 bytes 18446744073321613 Kb 18446744073321 Meg 18446744073 Gig 18446744 TB Unless you are from the future, there is no way you have a bunch of 18 Million Terrabyte drives in your server. So definitely my cache has HPA? I'll try using HDAT2 on it tomorrow. I guess that supermicro board might come in handy after all.
October 31, 201015 yr Author Just checked with HDAT2 and no HPA was detected on the Samsung, my cache drive.
October 31, 201015 yr Author Joe, Do you think I need to RMA this drive? I longer have permission to add stuff to the cache. I currently have about 3.8G filled in it.
October 31, 201015 yr Joe, Do you think I need to RMA this drive? I longer have permission to add stuff to the cache. I currently have about 3.8G filled in it. No... you probably just need to fix the file system. I'd copy the stuff off of it and then re-format it. It is far easier than rebuilding the reiserfs superblock for your level of experience)
Archived
This topic is now archived and is closed to further replies.