New answers tagged

0

Looks more like of the zfs related issue, After changing /etc/default/zfs with ZFS_INITRD_PRE_MOUNTROOT_SLEEP='15' the server boots normally


0

I still have no answer to recovering broken labels from one or more remaining, good labels. But to "rename" the device access point: zpool note-my-device-has-a-new-name /dev/sda /dev/disk/by-id/1234 do zpool export tank zpool import /dev/disk/by-id/1234 If the export fails (device is busy), you could search with lsof | grep tank for users, but ...


1

I found the problem by myself. I saw an article mentioning CMR and SMR. I checked my drives and I realized that I accidentally bought hard drives with SMR :( I will keep a mirror pool until I replaced the drives with new CMR drives. When I have the new drive I will also use a mirror pool. Thank you all!


1

I am in need of testing my Dell SAS Controller card. Simple. Replace with another one. Then you know whether or not the card has problems. None available? Can we get back to "professionalism" and "best practices" in the site rules? Ask a company to do it (and pay). Replacement testing is pretty much the only (and definitely the most ...


1

PERC controllers should only boot after firmware initialization is completed, so I suggest you to double-check that no hardware issues are present. That said, you have at least two methods to delay boot: increase the time window where you can press CTRL+R to enter the controller's firmware (but latest gen PERC seems to have dropped this key combo) increase ...


2

You probably have compression enabled, which converted any amount of zeros you wrote to a single, 512 byte-sized file. A simple du -hs file1 should reveal its actual allocated size.


0

zfs writes aren't really fast but not bad. zfs reads are extremely slow take a look by your own: 1) #Preparation: cd /mytestpool/mytestzfs;for f in urf{0..9};do dd if=/dev/urandom of=$f bs=1M count=102400;done; #Get a directory path with lots of subdirs and files (of ~50GB) and check size with eg: du -sh /mytestpool/mytestzfs/appsdir 2) reboot 3) time cat /...


0

Late answer, but maybe it can be useful to others... When ZFS reports "drive is in use" it means that ZFS can not exclusively open the needed block devices. It generally depends on the kernel having open the drive/blockdev for/by another storage component, as (but not limited to): mdraid multipath lvm As these build-in component are activated ...


0

As a first-order approximation raidz provides the random performances of a single disk, which for a 7.2K HDD are about 70 IOPS. Your test shows 50% less IOPS (ie: ~30 vs ~70) and this can be explained with the relatively large recordsize you selected. Especially for random writes, any recordsize larger than 4KB is going to face considerable read/modify/write ...


0

Turns out the problem was with the way I powered my drives. I have, without noticing put too many drives on single power rail. Once I distributed them evenly across the power rails, everything went back to normal.


0

I have managed to recover parts of the data by upgrading debian to bullseye (in order to have access to a more recent version of zdb) and importing the zpool with missing vdevs: echo 1 >> /sys/module/zfs/parameters/zfs_max_missing_tvds zpool import -o readonly=on vault Some of the filesystems on the zpool were corrupt, though. I have copied the intact ...


Top 50 recent answers are included