CH3MNAS: problemen met een 4TB HDD. Gelimiteerd tot 2TB?

[ZatarraNL]

Mijn vraag
Mijn NAS geeft een error tijdens het formateren van een HDD WD RED 4TB (zowel de NAS als de schijf zijn al een tijdje in gebruik, maar deze schijf heeft nog niet in de NAS gezeten). Wie kan mij vertellen wat het probleem is, en mij wellicht een niet te ingewikkelde oplossing geven? Ik heb weinig verstand van Linux.

Relevante software en hardware die ik gebruik
Ik gebruik de CH3MNAS met fonz fun_plug 0.7. Hierdoor kan ik inloggen met SSH (commandshell) en kan ik gebruik maken van rsync over SSH (belangrijk). De NAS heeft uitsluitend een backup-functie, ik heb namelijk nog een andere NAS. Dat hij niet meer nieuw meer is maakt mij dus helemaal niet uit.

Wat ik al gevonden of geprobeerd heb
Ik kan de 4TB WD RED wel prima formateren in EXT2 of EXT3 door middel van EaseUS op een Windows PC. Overigens probeert de NAS ook een EXT3 geformateerde schijf opnieuw te formateren naar EXT3. Idem voor EXT2. Na een schijfcontrole lijkt de schijf verder in orde (geen slechte sectoren). Vóór deze schijf gebruikte ik 2 schijven (1TB + 2TB) in JBOD opstelling in de CH3MNAS. Ik zou het liefst nu 4TB en 2TB in JBOD opstelling gebruiken.

Het lijkt erop dat de CH3MNAS is gelimiteerd tot 2TB. De CH3MNAS lijkt niet te beschikken over "parted", maar alleen over "fdisk". Ik krijg met het commando "fdisk /dev/sdb" de volgende waarschuwing:

WARNING: The size of this disk is 4.0 TB (4000787030016 bytes).
DOS partition table format can not be used on drives for volumes
larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID
partition table format (GPT).

Als iemand mij kan helpen, dan heel graag!

[ Voor 3% gewijzigd door ZatarraNL op 03-02-2017 21:22 ]

[Mijzelf]

Die NAS is behoorlijk gedateerd, volgens deze blog van begin 2009. Het zou kunnen dat hij geen GPT partitie tabel ondersteund. Als hij usb sticks accepteert, zou je er een gpt gepartitioneerde stick in kunnen prikken en met

cat /proc/partitions

kijken of hij de partitietabel herkent heeft. Dat zelfde kan ook met een interne harddisk, mits de NAS hem niet direct herpartitioneert.

[ZatarraNL]

Ja, de NAS is zeker gedateerd. Hij functioneert ook al een flink aantal jaartjes. Min of meer naar tevredenheid, maar enige tijd geleden toch maar overgestapt op een andere server omdat de doorvoersnelheid bleef steken op zo'n 16 Mb/s.

Maar als incremental backup voldoet het prima, ware het niet dat ik meer capaciteit nodig heb.

De schijf als USB toevoegen is interessant. Ik heb dan wel een extra voeding nodig, dus neemt het stroomverbruik toe. Bij voorkeur laat ik dat zitten. Bovendien gebruik ik dan misschien wel net zo lief een Raspberry Pi 3.

Is het mogelijk om GPT format toe te voegen dmv software? Dan kan het apparaat weer een paar jaartjes mee.

Werkt het eventueel om de 4TB schijf in twee partities op te delen? Wordt het dan wel door het apparaat geaccepteerd?

[Mijzelf]

Bovendien gebruik ik dan misschien wel net zo lief een Raspberry Pi 3.

Een RP3 haalt geen 16MB/sec. Die heeft een 100Mbit poort, en blijft dus steken op +/- 11MB/sec.

Is het mogelijk om GPT format toe te voegen dmv software?

Dat hangt ervan af wat je precies bedoelt. Het probleem bestaat uit 2 delen, de GPT maken en de GPT herkennen. De huidige firmware kan geen GPT maken, het feit dat parted ontbreekt is daarvoor een belangrijke aanwijzing. Dat kun je in principe omzeilen door de schijf buiten de NAS te partitioneren. (Of door ffp parted te installeren, maar dat komt op hetzelfde neer.)
Het herkennen wordt gedaan door de linux kernel, en dat staat in principe helemaal los van de mogelijkheid tot aanmaken. Er is geen gesharede code/libs.
Ik stelde al voor om te testen of de kernel het ondersteund. Als hij dat niet doet, moet je de kernel vervangen. Dat is niet triviaal.

Werkt het eventueel om de 4TB schijf in twee partities op te delen? Wordt het dan wel door het apparaat geaccepteerd?

Nee. Het is juist de partitie tabel die het probleem is.

Ik heb vroeger eens op een Lacie NAS die ook geen GPT ondersteunde met een loopdevice het ongeparitioneerde deel van de schijf als 'virtuele schijf' toegevoegd. Dat werkte, maar het was traag. Denk aan 5MB/sec. Ik vermoed dat dat komt omdat de loopdevice sector voor sector leest/schrijft, waardoor de schijf inefficiënt wordt gebruikt. Het zou overigens kunnen dat jouw kernel nieuwer is, en dat dat probleem is opgelost.

Later kwam ik de utility addpart tegen, waarmee je vanuit userspace een partitie kunt definiëren op een blockdevice. Dan kun je dus een parititie aanmaken voorbij de 2TB, of samen met zijn vriendje delpart zou je je 2TB parititie kunnen vergroten naar 4TB.
Dat moet wel na elke boot opnieuw gedaan, aangezien die partities niet zijn opgeslagen op schijf. (De inhoud van de partities natuurlijk wel, anders was het zinloos).
Dat idee heb ik overigens nog niet toegepast.

[ZatarraNL]

Beste Mijzelf, bedankt voor je reacties.

Een RP3 haalt geen 16MB/sec. Die heeft een 100Mbit poort, en blijft dus steken op +/- 11MB/sec.

Dat hindert niet. Voor een wekelijkse incremental backup voldoet dat voor mij. Snelheid is ondergeschikt.

Ik stelde al voor om te testen of de kernel het ondersteund.

Ik begrijp dat ik dit met een USB aansluiting zou kunnen testen?

Als hij dat niet doet, moet je de kernel vervangen. Dat is niet triviaal.

Nee, dat is (zeker voor mij) onhaalbaar...

Ik heb vroeger eens op een Lacie NAS die ook geen GPT ondersteunde met een loopdevice het ongeparitioneerde deel van de schijf als 'virtuele schijf' toegevoegd.

Hoe pak ik zoiets aan? Vooraf formateren tot 2TB als MBR? Wat voor loopdevice bedoel je hier?

Later kwam ik de utility addpart tegen, waarmee je vanuit userspace een partitie kunt definiëren op een blockdevice. Dan kun je dus een parititie aanmaken voorbij de 2TB, of samen met zijn vriendje delpart zou je je 2TB parititie kunnen vergroten naar 4TB.

addpart is op de NAS geinstalleerd. Ik kan een proberen of ik hier iets mee kan.

Dat moet wel na elke boot opnieuw gedaan, aangezien die partities niet zijn opgeslagen op schijf. (De inhoud van de partities natuurlijk wel, anders was het zinloos).
Dat idee heb ik overigens nog niet toegepast.

Dat is voor mij niet haalbaar. Het apparaat komt niet bij mij thuis te staan, maar op een locatie bij een vriend. Ik moet er vanuit kunnen gaan dat als het apparaat een herstart nodig heeft, de instellingen bewaard blijven.

Wat als ik 4k byte sectors gebruik in plaats van 512 byte sectors? Het lijkt erop dat mijn schijf dit ondersteund. Volgens deze website archlinux zou de Western Digital WD40EFRX 4k byte sectors ondersteunen. Kan dit samen met EXT2 of EXT3?

[ Voor 8% gewijzigd door ZatarraNL op 04-02-2017 17:14 ]

[Mijzelf]

Rolf82 schreef op zaterdag 4 februari 2017 @ 16:51:
[...]

Ik begrijp dat ik dit met een USB aansluiting zou kunnen testen?

Als die NAS het aansluiten van disks/USB sticks op de USB aansluiting ondersteund wel.
Met

cat /proc/partitions

vraag je aan de kernel op welke partities hij heeft herkend. Als hij geen partities ziet op een GPT geformatteerde schijf/USB stick (maar de schijf zelf wel), ondersteund hij dus geen GPT.

[...]

Hoe pak ik zoiets aan? Vooraf formateren tot 2TB als MBR? Wat voor loopdevice bedoel je hier?

Gewoon de firmware de schijf laten toevoegen. Dan zijn de eerste 2TB in gebruik. Vervolgens gebruik je losetup

losetup -o 2199023255552 /dev/loop0 /dev/sda

(Waarbij /dev/sda de 4TB schijf is). Hierna heb je een virtuele schijf /dev/loop0 die 1.9TB groot is. (Tot de eerstvolgende reboot)
Dat getal 219.. is de offset in bytes van de eerste sector voorbij de 2^32 sectors. I.v.m performance is het belangrijk dat het een veelvoud is van 512, en waarschijnlijk ook van 4096.
Overigens kan de firmware losetup bijna met zekerheid dit niet aan, dat zal een busybox applet zijn, en die kan zo'n groot getal niet parsen. Maar de ffp losetup kan dat waarschijnlijk wel.

[...]

Dat is voor mij niet haalbaar. Het apparaat komt niet bij mij thuis te staan, maar op een locatie bij een vriend. Ik moet er vanuit kunnen gaan dat als het apparaat een herstart nodig heeft, de instellingen bewaard blijven.

Daarvoor zijn startscripts uitgevonden. De reeks commando's die je extra partitie/virtuele schijf in de lucht moeten brengen kun je in een script in /ffp/start/ zetten.

[ Voor 6% gewijzigd door Mijzelf op 04-02-2017 17:26 ]

[ZatarraNL]

Is het idee om de schijf in te delen met 4k byte sectoren nog een overweging? Ik weet niet of ik de juiste software heb om dat voor elkaar te krijgen, maar ik wil dat wel proberen.

[Mijzelf]

Ik voel me stom. De eenvoudigste manier om partitioneringsproblemen te voorkomen is natuurlijk door niet te partitioneren. Je kunt gewoon de 'rauwe' schijf van een filesysteem voorzien.
Belangrijk is wel dat je niet in je webinterface gaat 'klooien' met die schijf. De firmware is zich er niet van bewust dat de schijf al in gebruik is.

Ik neem aan dat je rsnapshot of rsync gebruikt, helemaal buiten de firmware om? In dat geval maakt het natuurlijk helemaal niet uit of de firmware zich 'bewust' is van het filesysteem.

Rolf82 schreef op zaterdag 4 februari 2017 @ 17:27:
Is het idee om de schijf in te delen met 4k byte sectoren nog een overweging? Ik weet niet of ik de juiste software heb om dat voor elkaar te krijgen, maar ik wil dat wel proberend

Ja, dat zou leuk zijn, ware het niet dat de sector grootte door de schijf wordt gedicteerd. Uiteraard zou het mogelijk moeten zijn om daar een 'tussenlaag' in te brengen, maar dat komt neer op een kernelmodule. Niet triviaal.

[ZatarraNL]

Mijzelf schreef op zaterdag 4 februari 2017 @ 18:30:
Ik voel me stom. De eenvoudigste manier om partitioneringsproblemen te voorkomen is natuurlijk door niet te partitioneren. Je kunt gewoon de 'rauwe' schijf van een filesysteem voorzien.

Hoe doe ik dit? De schijf is al geformateerd met EXT3. Zou dat voldoende moeten zijn?
Rsync gebruik ik inderdaad buiten de firmware om. SMB-share gebruik ik wel met de firmware (via de webinterface), maar daar gebruik ik alleen de andere schijf voor (2TB).

[Mijzelf]

Je kunt een filesysteem op de 'rauwe' schijf zetten met

mkfs.ext3 /dev/sda

(Waarbij ik er vanuit ga dat /dev/sda de 4TB schijf is)
Weet niet of jouw systeem een mkfs.ext3 heeft. Misschien moet je mke2fs -j gebruiken.

Ik weet niet zeker of dit de partitie tabel overschrijft, dus die kun je beter eerst weghalen:

dd if=/dev/zero of=/dev/sda count=1
reboot

De reboot zorgt dat een eventuele partitie in ieder geval niet meer gemount is.

Hierna (partitie tabel wissen+filesysteem maken) moet je de schijf kunnen mounten

mkdir -p /tmp/mountpoint
mount /dev/sda /tmp/mountpoint

en zou 'df' een filesysteem van 4TB moeten laten zien.

Dat mounten zul je met een startscript moeten doen. De firmware doet het niet voor je.

Uiteraard moet je in de webinterface verder van die schijf afblijven. Je bent buiten de firmware om gegaan, de firmware kan er niets nuttigs mee. (Alleen wat gevaarlijks)

[ZatarraNL]

Hartelijke dank, Mijzelf! Het is gelukt.

Ik heb nu een 2e schijf, namelijk HD_b2 gemount. En deze kan ik zelfs via samba delen. De grootte van de schijf blijkt 3,58TB. De firmware (webinterface) laat ik maar helemaal links liggen.

Nu nog kijken hoe ik een script maak voor het automatisch mounten, bij voorkeur voordat SMB probeert deze de delen.

Toch nog een vraag over die sector size:

Ja, dat zou leuk zijn, ware het niet dat de sector grootte door de schijf wordt gedicteerd.

Deze site gaat over 'advanced format': archlinux
Er wordt in detail gesproken over sectors van 4k. De schijf die ik heb wordt hier ook genoemd (WD40EFRX). Er staat:
Reported sector size (bytes)
Logical: 512kb
Physical: 4096kb

All drives in this list have a physical sector size of 4096 bytes, but not all drives correctly report this to the OS. The actual value reported (via new fields in the ATA-8 spec) is shown in the table as the physical reported sector size. As this is the value partitioning tools use for alignment, it is important that it should be 4096 to avoid misalignment issues.
The logical sector size is the sector size used for data transfer. This value multiplied by the number of LBA sectors on the disk gives the disk capacity. Thus a disk with 4096 byte logical sectors will have a lower maximum LBA for the same capacity compared to a drive with 512 byte sectors. Drives with 512 byte logical sectors offer better compatibility with legacy operating systems (roughly those released before 2009) however drives with 4096 byte logical sectors may offer marginally better performance (e.g. more read/write requests may fit into the NCQ buffer.)

Ik heb alleen geen idee waar het hier over gaat, en of ik daar dus iets mee kan....

[ Voor 12% gewijzigd door ZatarraNL op 04-02-2017 20:44 ]

[Mijzelf]

Rolf82 schreef op zaterdag 4 februari 2017 @ 20:22:
Er wordt in detail gesproken over sectors van 4k. De schijf die ik heb wordt hier ook genoemd (WD40EFRX). Er staat:
Reported sector size (bytes)
Logical: 512kb
Physical: 4096kb


[...]


Ik heb alleen geen idee waar het hier over gaat, en of ik daar dus iets mee kan....

Een sector is de kleinste adresseerbare eenheid van een schijf. Als je adres 1000 op de sata bus zet krijg je sector 1000, 512 bytes beginnend op byte 512000. (Nou ja, eigenlijk op 511488, omdat de schijf begint bij sector 1, maar het principe is duidelijk)

De schijf heeft fysieke sectors van 4k, maar vanwege compatibiliteitsproblemen heeft hij logische sectors van 512 bytes. Er zit dus een stukje logica in die het opgegeven sector adres deelt door 8, die sector ophaalt, en dan de rest van de deling gebruikt als sub adres binnen de 4k sector.
Aangezien je die logica niet uit kunt zetten, heeft die schijf dus voor alle praktische toepassingen behalve alignment een sector grootte van 512.

Het MBR partitioneerbare gebied van een schijf wordt beperkt doordat de partities worden gedefinieerd met hun start- en eindsector, en voor beide getallen is 32 bits gereserveerd. Dus dus hoogst mogelijke eindsector is 2^32 - 1, en in bytes is dat 2TiB - 512 bytes.

Als je een echte 4k sector disk zou hebben, dus zowel logisch als fysiek, zou je met een MBR dus een 8 maal zo grote schijf kunnen partitioneren.
Of het verstandig is zoiets in je antieke NAS te stoppen is de vraag. Hoewel de Linux kernel best robuust is, zou het zomaar kunnen dat een 4k sector ergens een bug triggert. Tenslotte bestonden dat soort schijven nog niet toen die kernel uitkwam. Wel CD's, overigens, die een 2k sectors hebben. Dus het blocklayer is wel getest met sectoren > 512 bytes. Je kunt niet uitsluiten dat 4k gewoon zou werken.

Maar voor jouw probleem kun je hier allemaal niets mee. Tenzij jouw schijf een jumper zou hebben om de interne sector deler uit te zetten.

[ZatarraNL]

Fijne uitleg. Wel jammer, maar duidelijk. Bedankt!

[ZatarraNL]

De oplossing zoals je die heb aangedragen werkt, maar wel met een enorme performance hit. Ik haal maximaal 2,5Mb/s met rsync over een Gbit netwerk. En grote bestanden tussen de beide schijven in de NAS onderling max 3,7Mb/s. Misschien is dit ook wel alles wat ik eruit kan krijgen, maar zou alignment hier iets mee te maken kunnen hebben?

http://www.johannes-bauer.com/linux/wdc/

[Mijzelf]

Als het filesysteem misaligned is (en ik denk van niet) kun je daar niets aan doen. Je filesysteem begint gewoon waar de schijf begint. Zonder partitietabel valt daar niets aan te schuiven.

Maar ik denk niet dat je gemeten waarden daardoor komen. Tenzij je erg worst case aan het meten bent, zou je nauwelijks verschil tussen wel en niet aligned moeten kunnen meten. Misalignment wordt afgehandeld door de schijf, en die is relatief zoveel sneller dan de NAS, dat de performance hit nauwelijks merkbaar is.

(Worst case wel. Stel dat je random 4k blokken zou wegschrijven, die aligned zijn t.o.v het filesysteem, dan wordt je thoughput beperkt door de IOPS van de schijf. Typisch ongeveer 100/sec, dus je schrijft 400k per seconde.
Als het filesysteem misaligned is, kan de schijf dat blok van 4k niet zomaar wegschrijven, omdat hij alleen hele 4k sectoren kan schrijven. Die 4k is verdeeld over 2 sectoren, dus moet hij eerst die 2 sectoren inlezen, die 4k data erin passen, en dan de 2 sectoren weer wegschrijven. Probleem is dat hij tussen het inlezen en het wegschrijven een hele diskomwenteling moet wachten, tot de kop weer boven die sectoren is.
Bij 7200tpm duurt dat 1/120 seconde, 8 msec. Dus in plaats van elke 10 msec 4k wegschrijven wordt dat elke 18 msec. Bijna een halvering.)

Hoe heb je de snelheid gemeten? Met rsync toevallig? Die staat erom bekend dat de eerste kopie traag gaat. De grote kracht van rsync zit in het syncen naderhand.

Rauwe doorvoer van die schijf kun je testen met

time dd if=/dev/zero of=/mnt/HD_b2/GroteFile bs=1M count=1k

Dit schrijft een file van 1 GiB in blokken van 1MiB, en meet de tijd. Zou je ook voor de 2TB schijf kunnen doen. Ik verwacht dat ze allebei rond de 40MB/sec halen, en dat is dan de maximale thoughput van je sata bus. Die schijven kunnen natuurlijk harder.

[ZatarraNL]

Dat geeft mij de volgende waardes:

1073741824 bytes (1.1 GB) copied, 20.7084 s, 51.9 MB/s
Voor de 4Tb WD
Dus niets mis mee. Scheelt weer.

1073741824 bytes (1.1 GB) copied, 71.9136 s, 14.9 MB/s
Voor de 2TB
Wel beduidend lager, maar voldoende snel voor mij om er geen hinder van te ondervinden.

Bedankt.

[ Voor 49% gewijzigd door ZatarraNL op 06-02-2017 22:27 ]

[Mijzelf]

Rolf82 schreef op maandag 6 februari 2017 @ 22:21:
14.9 MB/s

Da's raar. Waarom zou die trager zijn? Krijg je kernel messages over de transfer (dmesg)? Gaat het probleem mee als je de schijven omwisselt? SMART?

[ZatarraNL]

Ja, vond ik ook raar. Ik heb het zojuist nog maar eens getest. Kom nu op een nette 50,1 Mb/s. Dus er zal wel iets tijdelijk mis zijn geweest.

[HRodenhuis]

Beste Zatarra,

Ik loop met een CH3MNAS tegen dezelfde problemen aan met 2 4TB schijven. Ik ben bang dat ik technisch iets minder onderlegd ben, maar wellicht is jouw oplossing te herhalen. Kun je nog terughalen hoe je uiteindelijk de NAS aan de praat hebt gekregen met de 4TB schijf?

Alvast dank!

[ZatarraNL]

HRodenhuis schreef op woensdag 25 maart 2020 @ 23:01:
Beste Zatarra,

Ik loop met een CH3MNAS tegen dezelfde problemen aan met 2 4TB schijven. Ik ben bang dat ik technisch iets minder onderlegd ben, maar wellicht is jouw oplossing te herhalen. Kun je nog terughalen hoe je uiteindelijk de NAS aan de praat hebt gekregen met de 4TB schijf?

Alvast dank!

Hoi HRodenhuis,
Dat is heel lang geleden. Ik weet dat het gelukt is met de oplossing van Mijzelf van 4 februari 19.27u. Hij draait nog steeds, maar ik ga hem op korte termijn toch een keer vervangen. Ik vertrouw de veiligheid van de software niet meer.

Verder ben ik ook geen expert, dus ik zou het eens proberen met de oplossing van Mijzelf. Voorwaarde is natuurlijk dat je de geen gebruik meer maakt van de webpagina voor instellingen, maar dat je fonz funplug installeert en daarmee toegang regelt via ssh.

Succes!