What internally limits these things?
ZFS's limits are based on fixed-size integers because that's the fastest way to do arithmetic in a computer.
The alternative is called arbitrary-precision arithmetic, but it's inherently slow. This is why arbitrary-precision arithmetic is an add-on library in most programming languages, not the default way ...
(this started as a comment but became too long so is now an answer)
Unfortunately, the answer is "No". There isn't a faster, or smarter way to do this.
ZFS filesystems (even though they are on the same pool) are separate filesystems. Neither mv nor any other tool can just move the block pointers or whatever so that files that were on fs_a are now on fs_b....
Well, it really depends on how read-only you want the pool to be. And no, that's not a joke.
First, a bit of terminology: in ZFS, you import a pool, and optionally mount the (any) file systems within it. You can import a pool without mounting any file systems by passing -N to zpool import and then later on mount any desired file systems using zfs mount. (...
zpool attach pool old-disk new-disk
That will convert old-disk into a mirror with both old-disk and new-disk and start resilvering after which you can detach the old disk.
zpool detach pool old-disk
Tested with loop devices:
# truncate -s 1G a b
# truncate -s 1200M c
# losetup /dev/loop0 a
# losetup /dev/loop1 b
# losetup /dev/loop2 c
# zpool create ...
If you store the snapshots in files, as opposed to in the file system (e.g.
with zfs receive), I'm afraid, this is not possible.
ZFS on the receiving side
If you use ZFS on the sending and on the receiving side you can avoid having
to transfer the whole snapshot and only transfer the differences of the
snapshot compared to the previous one:
ssh myserver '...
Tracking freed blocks is unavoidable in any decent file system and ZFS is no exception. There is however a simple way under ZFS to have a nearly instantaneous directory deletion by "deferring" the underlying cleanup. It is technically very similar to Gilles' suggestion but is inherently reliable without requiring extra code.
If you create a snapshot of your ...
DTrace is able to report on vfs information in FreeBSD (as well as a raft of other probes). DTrace is enabled by default in the 10 kernel so all you need to do is load the module then run the dtrace script.
Load the DTrace module
Get the vfssnoop.d script from the FreeBSD forums. The whole thread is a treasure trove for disk monitoring....
Disclaimer: As I've never used zvols, I cannot say if they are any different in replication than normal filesystems or snapshots. I assume they are, but do not take my word for it.
Your question is actually multiple questions, I try to answer them separately:
How to replicate/mirror complete pool to remote location
You need to split the task into two ...
In order to view the current value of a specific setting like ashift, you will need to use the zdb command instead of the zpool command.
Running zdb on its own with no arguments will give you a view of any pools found on the system, and their vdevs, and disks within the vdevs.
The actual answer by @cas is good but have some corrections to be applied.
So let's take a fresh installation of Debian 9 and assuming that the contrib non-free repositories are also not enabled.
Step 0 - Enable the contrib non-free repositories
I used sed to find and replace the word main inside /etc/apt/sources.list
sed -i 's/main/main contrib non-free/...
Yes, it is possible by using fake file-backed disks for your redundant ones. Of course, not supported and you should have a backup, so simulate it first with small files on your old pool to see if everything works as expected.
For details see https://email@example.com/msg22993.html and https://www.mail-archive.com/zfs-discuss@...
By default the USERSHARE feature of samba is disabled in Fedora. Enabling it is not enough as libshare in the ZFSOnLinux requires a specific usershare path to be set.
To get it working set the following in /etc/samba/smb.conf:
usershare path = /var/lib/samba/usershares
usershare max shares = 100
usershare allow guests = yes
You can't. It's now in the pool as a single-drive vdev. vdevs can not be removed from a pool.
That's the bad news.
The worse news is that you've now effectively got a RAID-0 with your raidz2-0 vdev and the c2t13d0 vdev. This is NOT good. It's doubleplusungood.
Your options are:
to live with the pool you have created
backup, destroy and re-create the ...
Well, how to do it is easy enough: ls gets its list from a syscall (or, on Linux, libc function) called readdir. Changing into a directory is done with a separate syscall, chdir. stat is also a different syscall, as are most of the other file operations.
In short, "what's in this directory?" and "access this directory" are completely separate requests of ...
I would almost a zero maintenance once the pool and filesystems are created. zpool scrub is not suggested to be often, but would not hurt to be around once in like two-three months but prefer doing it manually.
Monitoring the zpool status or zpool status -v output should give you a clue whether your pool is healthy or if any of the disks are in degrated ...
ZFS on Linux does not have a critical mass following, whatever that may be. ZFS will effectively lock you in. The underlying format is incompatible with rescue disks, and distributions for which you will find ZFS is rare.
I would tend to overlook these limits due to my bias towards ZFS. You may want to google for a service provider that provides SmartOS/...
/boot is not encrypted (the BIOS would have no way to decrypt it...). It could be ext4, but there really isn't any need for it to be. It usually doesn't get written to. The BIOS reads GRUB from the MBR, then GRUB reads the rest of itself, the kernel, and the initramfs from /boot. The initramfs prompts you for the passphrase. (Assumably, its using cryptsetup ...
The thing that strike me most in your case is the partitioning.
That is a disk might be used by more than one vdev (aka group), which is of course a major risk, but I understand perfectly that this is an old PC giving a new life as a NAS (I have one at home as well).
There is no major loophole in your schema, except that:
a pool can be composed of ...
I don't know what you are trying to achieve so I can only describe what your command is actually doing.
You are reading from a special device which returns an infinite number of zero (or NUL) bytes.
You are creating a new file using the above (infinite) input.
You read and write the infinite data stream in megabyte ...
What you're asking for is impossible. Or, more precisely, there's a cost to pay when deleting a directory and its files; if you don't pay it at the time of the deletion, you'll have to pay it elsewhere.
You aren't just removing a directory — that would be near-instantaneous. You're removing a directory and all the files inside it and also recursively ...
Okay, you have made a bit of a mess for yourself, but it looks like it's fixable.
The first mistake you made was to zpool add the new drive, instead of zpool attach (attach an additional device to a mirror) or even better zpool replace with the old device still present in the pool metadata. The correct way to replace the device would have been to
# zpool ...
$(...) is command substitution. You don't want the output of zfs send to be taken as a file name for nc to read from. You want to send the output of zfs send as input to pigz while pigz sends its output to netcat, so:
zfs send -R "$zpool@label" | pigz | netcat "$remote_upload_address" "$remote_port"
Don't use UDP. UDP, contrary to TCP provides no guarantee ...
ZFS deduplication only will take effect on files deployed after you enable deduplication.
It won't affect older files before deduplication was enabled.
To see how much dedup is saving, use the command zpool status -D poolname and pay attention to the Total allocated blocks versus Total referenced blocks.
Use the list option on the zfs command built into FreeBSD.
$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
zroot 4.41G 17.4G 88K none
zroot/ROOT 3.49G 17.4G 88K none
zroot/ROOT/default 3.49G 17.4G 3.15G legacy
zroot/tmp 112K 17.4G 112K /tmp
As you're using zsh, I recommend tab completion or shell globbing (always echo/ls before removing). If those doesn't work, you have a few options:
Check your filename through a hex dump and use $'...' to input it
% touch akorg✽
% ls | grep akorg | hexdump -C
00000000 61 6b 6f 72 67 e2 9c bd 0a |akorg....|
% ls $'akorg\...
Putting your zpool as files on an existing file system means you're relying on that file system to provide consistency (which sounds dangerous at best) and also that ZFS can't take good advantage of caching. I'm not sure how well ZFS would handle the transfer from files to physical devices; the file system itself probably wouldn't have any real complaints, ...
What really matters when dealing with ZFS pools and datasets portability is their versions. You can always import a pool using a version less or equal to the one your OS supports, and the same rule applies for datasets (i.e. file systems, zvols and snapshots).
So if you plan to move ZFS pools from some OSes to different ones, make sure you select the ...
You state data integrity and minimum risk of data loss as main concerns.
Running ZFS with only 2GiB of memory is risky and not advisable. Too little
RAM kills the performance and was the cause of numerous unmountable pools in
the past. The FreeNAS project states 8GiB of RAM as
Furthermore, since your concern is data loss, you will want to use ECC ...