Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A much easier way to test ZFS configurations is to use files instead[0]:

  $ mkfile 128m /home/user/disk1
  $ mkfile 128m /home/user/disk2
  $ mkfile 128m /home/user/disk3
  $ zfs create tank mirror /home/user/disk1 /home/user/disk2 /home/user/disk3
[0]: https://flux.org.uk/tech/2007/03/zfs_tutorial_1.html


Author here, thanks for the heads up. It doesn't look like mkfile is included with the Jessie base system I was using to test. For those wishing to use this method it looks like the xfsprogs package contains xfs_mkfile which operates the same as parent's example.


mkfile is standard on Solaris. On Debain use fallocate:

  $ fallocate -l 128MB /home/user/disk1


there is also 'truncate'. Especially nice about truncate is the ability to create sparse files. So if you want to test how big a pool would be with three 1TB disks without actually using 3TB of allocated space: 'truncate -s 1T file1.img'. voila, a 1tb file that only takes kilobytes upon creation of a zpool.


Is there an advantage of using fallocate over say, dd to pipe random or zeroes to a file?


fallocate doesn't do any IO; it's much faster.

From the fallocate man page:

> For filesystems which support the fallocate system call, preallocation is done quickly by allocating blocks and marking them as uninitialized, requiring no IO to the data blocks. This is much faster than creating a file by filling it with zeros.


[deleted]


Yes they would. But you should never use this in production. Only for the purpose of learning/testing ZFS.


Sorry, I deleted my comment about the same time you replied to it. I realized both you and TFA were discusing testing setups, not actual hard drive redundancy setups.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: