June 3, 20188 yr So after a quick search for 'Unmountable: Unsupported partition layout', i get results, that people couldn't mount after a unraid version upgrade. This is not the case for me. I just bought an NVME ssd, and installed it. Switched all my shares to cache: yes (moved everything to array) removed the old sata cache, put in the new nvme one in, set my shares back to (if needed) to Cache: Prefer), run mover, to move it back to cache in some cases. Soooo. during the mover, i wanted to test the speed. I'm a linux noob, did a quick google search, and ended up on this page: http://www.fpgadeveloper.com/2016/07/measuring-the-speed-of-an-nvme-pcie-ssd-in-petalinux.html so i did the time dd if/dev... off/dev ... command, it showed some false numbers (3GB, then 600MB, whatever) tried it with my other drivers as well dev/sdc sdb, still showed 300-400MB for sata HDD-s, so it was obv. not valid. whatever I clicked shares tab, and some of them were missing already, hmm after the mover finished, i restarted it, and boom, multiple drives unmountable. I have 2 array drives (8TB+3TB) (no parity yet, i know...) 1 cache (used to be sata, now nvme) 2 unassigned (2TB+4TB) I THINK i did this speedtest command on the 8TB (now unmountable), on the NVME drive (now unmountable) and the 2 unassigned drive (I think unmountable, but there is no text on the main screen). So I can only mount the 3TB drive, on which (i think) I didn't run the above mentioned 'speedtest' command. I don't know anything about filesystems etc, it's just the only thing I can think of, which could have messed up my partitions. they were always ok before. I only found this error, when i installed brand new drives, but then i just formated them, and i was good to go. SO, DID I LOSE MOST OF MY DATA? Is there a way to fix these partitions/drives? I can't mount ANY drives via unassigned devices, only the 3TB, which can be mounted via the array as well. Any idea how can i fix the partitions? Could the 'dd' command messed up all my partitions? any input would be appriciated thank you!
June 3, 20188 yr Author after reading up on the dd command, did this command just overrode my partition, without any questions, and now all of it is gone? can some of it be repaired salvaged? i did 20GIG writes, does it use empty sectors, or just the first 20gig? can xfs_reapir or something like that help me?
June 3, 20188 yr dd is a copy command. if=xx means where to read from of=xx means where to write to So of=/dev/sdX is a very, very, very bad idea if you want to keep the content of /dev/sdX. A common use for dd would be something like: dd if=/dev/sda of=/dev/sdb bs=1M which is a great way to copy all contents from disk sda to disk sdb. A way to test raw read speed with dd is dd if=/dev/sdX of=/dev/null This means read raw data from a disk but throw away the data (/dev/null as output device is the Unix way of throwing the way some unwanted output data) If you just run it for a short time, or specified a limiter - like count=xx - then only the start of the destination disks are overwritten. So possibly, you could managed to find some content by getting a really good rescue software. The good thing with unRAID is that every data disk has a stand-alone file system and no individual file is striped over multiple disks.
June 3, 20188 yr Author 2 minutes ago, pwm said: dd is a copy command. if=xx means where to read from of=xx means where to write to So of=/dev/sdX is a very, very, very bad idea if you want to keep the content of /dev/sdX. A common use for dd would be something like: dd if=/dev/sda of=/dev/sdb bs=1M which is a great way to copy all contents from disk sda to disk sdb. A way to test raw read speed with dd is dd if=/dev/sdX of=/dev/null This means read raw data from a disk but throw away the data (/dev/null as output device is the Unix way of throwing the way some unwanted output data) If you just run it for a short time, or specified a limiter - like count=xx - then only the start of the destination disks are overwritten. So possibly, you could managed to find some content by getting a really good rescue software. The good thing with unRAID is that every data disk has a stand-alone file system and no individual file is striped over multiple disks. Hi i THINK I did the following command: dd if=/dev/sdc of=/dev/null bs=2M count=10000 I did a count=1000, and then 10.000, so it means i have overwritten the first 20-22GB of each disk. how can i go about fixing these drives? is there a way i can mount them on this unraid machine? i don't have any other linux machine, which can read xfs, only my main win10 PC. can you point me to the right direction maybe? thank you!
June 3, 20188 yr Author reading your post again: wouldn't the above command do the reading? it would read 20gig of sdc, and write it to 'dev/null', so i wouldn't lose my data, right? if my partions are unradable, it means i must have done it the other way, right? write 20gig of /dev/null to sdc. Edited June 3, 20188 yr by LSL1337
June 3, 20188 yr The above command is non-destructive - it just reads lots of data without overwriting anything. It's a common method to test read speed. As long as you had of=/dev/null, nothing should have broken. The really dangerous part is if you did any write speed tests with dd if=/dev/zero of=/dev/sdX bs=1M count=1000 in which case dd will measure the write speed by zero-filling the start of the targeted disk.
June 3, 20188 yr Author I run both on the first disk (cache), then only the second on the others. looks like it was the other way around... thank you for your help
June 5, 20188 yr Author any tipps for what software to use? anyone any experience with xfs restore? Or any other ideas for btrfs restore (i still have the old ssd cache, from which i moved the data to the array. can that be recovered?) filesystem is ok, but the files were moved (copy and delete i guess), no write activity on the drive since. i tried XFS restore apps on windows, so far no luck... same for btfrs 1-2 small files are recovered, but nothing substantial
Archived
This topic is now archived and is closed to further replies.