Search results

The -d parameter expects a directory argument, not a block device. But I think the problem is that you have a weird partition structure. It looks as if your /dev/sdX devices have a /dev/sdX1 partition which are further partitioned but the Linux ZFS framework expects the ZFS vdevs to be on the...

Do you see any keys under /etc/letsencrypt/keys/? You should have your key there named "nnnn_key-letsencrypt.pem" if you used the upstream LE toolset.

Thanks. Well, yes, if that table I linked earlier holds true information, this drive is pretty slow for sync write ops.

@sahostking, for future reference, can you tell what SSD models you're using? BTW, if you invested in that many of them, even if it may sound a little weird, you should invest in another one that has fast sync write rates and use it as log device. But for mostly-read workloads, I can imagine...

Sorry, did I understand you right, you use 6 pieces of 1TB SSD drives? Yet you get that fsyncs/sec? Anyway, some consumer grade drives are supposedly very bad for sync writes, according to this link. It might stem from the fact that these drives don't employ mechanisms to defend against...

Could you please link us to the official statement from Intel regarding the factory underprovisioning of these models? Thanks.

I found these 2 post to be useful for the above discussion: http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg34677.html http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg34684.html An excerpt:

Well, that thread assumes one's using dedup which I'm not interested in. It's a lot of stuff, bet definitely not a definite answer :) I think as a general guidance, simple SSD caching calculations would suit the original question by @brickmasterj better as well.

@mir, thanks for the added wiseness. Just as a side note I'd like to point out hat SLOG usage is influenced by certain dataset properties, too, sync writes aside. While we're at it, do you have a definite source of answer for the L2ARC/memory ratio? I havent't been able to gather very useful...

Well, let me try with some general hints. The write cache is actually called SLOG, ZIL (ZFS Intent Log, not cache) is always present in RAM and is necessary for ZFS operation. SLOG is something that supports writing ZIL contents to disk by layering a cache device - mostly a fast SSD - between...

Ah, I see, thanks for the explanation. Our main use case for this is that we use a lot of small development/build servers for which we don't need this kind of limitation. I can live with that if the command line API continues to provide this feature. Thanks!

I've run a quick test. When I issue the following command: pct create 100 /var/lib/vz/template/cache/debian-8.0-standard_8.0-5_amd64.tar.gz -rootfs=/var/lib/lxc/100 Then it creates a working CT using a newly created directory at /var/lib/lxc/100, using simple file storage, without any form of...

Yes, I think it's called root filesystem size (can't check it right now). In short, I want an LCX CT in directory storage, not raw, and without setting a quota on it. With the base lxc-* tool set, it's possible.

I'm evaluating the new PVE 4.1 environment and have stumbled upon a problem related to limiting disk quotas of LXC containters. I have an existing ext4 volume I want to use for CT storage, and there used to be the possibility in 4.0 to enter a 0 as quota. It used to turn on directory based...

Unfortunately, TRIM support is not the only difference, see here, for example. But I agree that instead of IDE, virtio-blk would be a better choice feature and performance-wise. Where I experienced this error I switched to it and it worked just fine in place of virtio-scsi. Anyway I'm rather...

For me, RED drives worth it because of their longer warranty period (3y). I'm using several ZFS pools built of those drives, mainly for online backup purposes. A significant difference between the Red and Green is that the Reds have a better suspension system to damp vibrations more effectively...

Hmm, the nodes where I've seen this all have HWRAID, Adaptec, in particular. Maybe the issue has to do something with it or their drivers?

I had this experience on PVE 3.4 + 3.10 Linux kernel, too. It doesn't have to be iSCSI. One of my VMs happened to even boot from the hypervisor disk instead of its own vdisk on top of its assigned LVM volume. I was prepared to reinstall the whole node from scratch but fortunately (and strangely)...

I'm also interested in a similar thing, and have found this. I can't test it ATM but I'm curious if you could succeed.

It's also possible with Proxmox. Did you setup dynamic memory allocation for the VMs in question when creating them (you can change it later)? Even if you did, what do you think will happen when all VMs start to consume all of their RAM?