Re: [zfs-discuss] ZFS questions
Darren Reed wrote: Solid state disk often has a higher failure rate than normal disk and a limited write cycle. Hence it is often desirable to try and redesign the filesystem to do fewer writes when it is on (for example) compact flash, so moving hot blocks to fast storage can have consequences. Solid state storage does not necessarily mean flash. For example, I have recently performed some testing of Sun's Directory Server in conjunction with solid state disks from two different vendors. Both of these used standard DRAM, so there's no real limit to the number of writes that can be performed. They have lots of internal redundancy features (e.g., ECC memory with chipkill, redundant power supplies, internal UPSes, and internal hard drives to protect against extended power outages), but both vendors said that customers often use other forms of redundancy (e.g., mirror to traditional disk, or RAID across multiple solid-state devices). One of the vendors mentioned that both SVM and VxVM have the ability to designate one disk in a mirror as write only (unless the other has failed) which can be good for providing redundancy with cheaper, traditional storage. All reads would still come from the solid state storage so they would be very fast, and as long as the write rate doesn't exceed that of the traditional disk then there wouldn't be much adverse performance impact from the slower disk in the mirror. I don't believe that ZFS has this capability, but it could be something worth looking into. The original suggestion provided in this thread would potentially work well in that kind of setup. ZFS with compression can also provide a notable win because the compression can significantly reduce the amount of storage required, which can help cut down on the costs. Solid state disks like this are expensive (both of the 32GB disks that I tested list at around $60K), so controlling costs is important. Neil ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: multiple copies of user data
Darren J Moffat wrote: While encryption of existing data is not in scope for the first ZFS crypto phase I am being careful in the design to ensure that it can be done later if such a ZFS framework becomes available. The biggest problem I see with this is one of observability, if not all of the data is encrypted yet what should the encryption property say ? If it says encryption is on then the admin might think the data is safe, but if it says it is off that isn't the truth either because some of it maybe in encrypted. I would also think that there's a significant problem around what to do about the previously unencrypted data. I assume that when performing a scrub to encrypt the data, the encrypted data will not be written on the same blocks previously used to hold the unencrypted data. As such, there's a very good chance that the unencrypted data would still be there for quite some time. You may not be able to access it through the filesystem, but someone with access to the raw disks may be able to recover at least parts of it. In this case, the scrub would not only have to write the encrypted data but also overwrite the unencrypted data (multiple times?). Neil ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: multiple copies of user data
Matthew Ahrens wrote: Matthew Ahrens wrote: Here is a proposal for a new 'copies' property which would allow different levels of replication for different filesystems. Thanks everyone for your input. The problem that this feature attempts to address is when you have some data that is more important (and thus needs a higher level of redundancy) than other data. Of course in some situations you can use multiple pools, but that is antithetical to ZFS's pooled storage model. (You have to divide up your storage, you'll end up with stranded storage and bandwidth, etc.) Given the overwhelming criticism of this feature, I'm going to shelve it for now. This is unfortunate. As a laptop user with only a single drive, I was looking forward to it since I've been bitten in the past by data loss caused by a bad area on the disk. I don't care about the space consumption because I generally don't come anywhere close to filling up the available space. It may not be the primary market for ZFS, but it could be a very useful side benefit. Out of curiosity, what would you guys think about addressing this same problem by having the option to store some filesystems unreplicated on an mirrored (or raid-z) pool? This would have the same issues of unexpected space usage, but since it would be *less* than expected, that might be more acceptable. There are no plans to implement anything like this right now, but I just wanted to get a read on it. I don't see much need for this in any area that I would use ZFS (either my own personal use or for any case in which I would recommend it for production use). However, if you think that it's OK to under-report free space, then why not just do that for the data ditto blocks. If one or more of my filesystems are configured to keep two copies of the data, then simply report only half of the available space. If duplication isn't enabled for the entire pool but only for certain filesystems, then perhaps you could even take advantage of quotas for those filesystems to make a more accurate calculation. --matt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
