Zfs encryption property for freebsd 8.3
Hi,
I want to encrypt some disk on my server with Zfs encryption property but it is
not available.
Are there anybody have got an experience about this?
[url]http://docs.oracle.com/cd/E23824_01/html/821-1448/gkkih.html#scrolltoc[/url]
[url]http://www.oracle.com/technetwork/articles/servers-storage-admin/manage-zfs-encryption-1715034.html[/url]
These are good explanations but I got an error and output shows all property;
[root@HP ~]# zpool status
pool: output
state: ONLINE
scan: none requested
config:
NAMESTATE READ WRITE CKSUM
output ONLINE 0 0 0
ad0s1eONLINE 0 0 0
errors: No known data errors
[root@HP ~]# zfs create -o encryption=on output/home
cannot create 'output/home': invalid property 'encryption'
[root@HP ~]# zfs get encryption
bad property list: invalid property 'encryption'
usage:
get [-rHp] [-d max] [-o "all" | field[,...]] [-t type[,...]] [-s
source[,...]]
<"all" | property[,...]> [filesystem|volume|snapshot] ...
The following properties are supported:
PROPERTY EDIT INHERIT VALUES
availableNO NO
clones NO NO [,...]
compressratioNO NO <1.00x or higher if compressed>
creation NO NO
defer_destroyNO NO yes | no
mounted NO NO yes | no
origin NO NO
refcompressratio NO NO <1.00x or higher if compressed>
referenced NO NO
type NO NO filesystem | volume | snapshot
used NO NO
usedbychildren NO NO
usedbydatasetNO NO
usedbyrefreservation NO NO
usedbysnapshots NO NO
userrefs NO NO
written NO NO
aclinherit YES YES discard | noallow | restricted |
passthrough | passthrough-x
aclmode YES YES discard | groupmask | passthrough |
restricted
atime YES YES on | off
canmountYES NO on | off | noauto
casesensitivity NO YES sensitive | insensitive | mixed
checksumYES YES on | off | fletcher2 | fletcher4 | sha256
compression YES YES on | off | lzjb | gzip | gzip-[1-9] | zle
copies YES YES 1 | 2 | 3
dedup YES YES on | off | verify | sha256[,verify]
devices YES YES on | off
execYES YES on | off
jailed YES YES on | off
logbias YES YES latency | throughput
mlslabelYES YES
mountpoint YES YES| legacy | none
nbmand YES YES on | off
normalizationNO YES none | formC | formD | formKC | formKD
primarycacheYES YES all | none | metadata
quota YES NO| none
readonlyYES YES on | off
recordsize YES YES 512 to 128k, power of 2
refquotaYES NO| none
refreservation YES NO| none
reservation YES NO| none
secondarycache YES YES all | none | metadata
setuid YES YES on | off
sharenfsYES YES on | off | share(1M) options
sharesmbYES YES on | off | sharemgr(1M) options
snapdir YES YES hidden | visible
syncYES YES standard | always | disabled
utf8only NO YES on | off
version YES NO 1 | 2 | 3 | 4 | 5 | current
volblocksize NO YES 512 to 128k, power of 2
volsize YES NO
vscan YES YES on | off
xattr YES YES on | off
userused@... NO NO
groupused@...NO NO
userquota@... YES NO| none
groupquota@... YES NO| none
written@ NO NO
Sizes are specified in bytes with standard units such as K, M, G, etc.
User-defined properties can be specified by using a name containing a colon (:).
The {user|group}{used|quota}@ properties must be appended with
a user or group specifier of one of these forms:
POSIX name (eg: "matt")
POSIX id(eg: "126829")
SMB name@domain (eg: "matt@sun")
SMB SID (eg: "S-1-234-567-89")
[root@HP ~]#
-
How can I use or add encryption property to FreeBsd 8.3?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe,
Re: Zfs encryption property for freebsd 8.3
Le 03/09/2013 14:14, Emre Çamalan a écrit : > Hi, > I want to encrypt some disk on my server with Zfs encryption property but it > is not available. "That would require ZFS v30. As far as I am aware Oracle has not released the code under CDDL." From http://forums.freebsd.org/showthread.php?t=30036 So you can use ZFS pools on GELI volumes, it can be a good start. I not play with it. -- Florent Peterschmitt | Please: flor...@peterschmitt.fr| * Avoid HTML/RTF in E-mail. +33 (0)6 64 33 97 92 | * Send PDF for documents. http://florent.peterschmitt.fr | * Trim your quotations. Really. Proudly powered by Open Source | Thank you :) signature.asc Description: OpenPGP digital signature
Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking
On Mon, Sep 02, 2013 at 11:49:33AM +0300, Alexander Motin wrote: > Hi. > > I would like to invite more people to review and test my patches for > improving CAM and GEOM scalability, that for last six months you could > see developing in project/camlock SVN branch. Full diff of that branch > against present head (r255131) can be found here: > http://people.freebsd.org/~mav/camlock_patches/camlock_20130902.patch I'm building my kernel right now. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Zfs encryption property for freebsd 8.3
On Tue, Sep 3, 2013 at 6:22 AM, Florent Peterschmitt wrote: > Le 03/09/2013 14:14, Emre Çamalan a écrit : >> Hi, >> I want to encrypt some disk on my server with Zfs encryption property but it >> is not available. > > "That would require ZFS v30. As far as I am aware Oracle has not > released the code under CDDL." Oracle's ZFS encryption is crap anyway. It works at the filesystem level, not the pool level, so a lot of metadata is in plaintext; I don't remember how much exactly. It's also highly vulnerable to watermarking attacks. > > From http://forums.freebsd.org/showthread.php?t=30036 > > So you can use ZFS pools on GELI volumes, it can be a good start. I not > play with it. GELI is full-disk encryption. It's far superior to ZFS encryption. > > -- > Florent Peterschmitt | Please: > flor...@peterschmitt.fr| * Avoid HTML/RTF in E-mail. > +33 (0)6 64 33 97 92 | * Send PDF for documents. > http://florent.peterschmitt.fr | * Trim your quotations. Really. > Proudly powered by Open Source | Thank you :) > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Zfs encryption property for freebsd 8.3
Le 03/09/2013 16:53, Alan Somers a écrit : > GELI is full-disk encryption. It's far superior to ZFS encryption. Yup, but is there a possibility to encrypt a ZFS volume (not a whole pool) with a separate GELI partition? Also, in-ZFS encryption would be a nice thing if it could work like an LVM/LUKS where each logical LVM volume can be encrypted or not and have its own crypt key. I saw that Illumos has ZFS encrytion in the TODO list. -- Florent Peterschmitt | Please: flor...@peterschmitt.fr| * Avoid HTML/RTF in E-mail. +33 (0)6 64 33 97 92 | * Send PDF for documents. http://florent.peterschmitt.fr | * Trim your quotations. Really. Proudly powered by Open Source | Thank you :) signature.asc Description: OpenPGP digital signature
Re: Zfs encryption property for freebsd 8.3
On Tue, Sep 3, 2013 at 9:01 AM, Florent Peterschmitt wrote: > Le 03/09/2013 16:53, Alan Somers a écrit : >> GELI is full-disk encryption. It's far superior to ZFS encryption. > > Yup, but is there a possibility to encrypt a ZFS volume (not a whole > pool) with a separate GELI partition? You mean encrypt a zvol with GELI and put a file system on that? I suppose that would work, but I bet that it would be slow. > > Also, in-ZFS encryption would be a nice thing if it could work like an > LVM/LUKS where each logical LVM volume can be encrypted or not and have > its own crypt key. My understanding is that this is exactly how Oracle's ZFS encryption works. Each ZFS filesystem can have its own key, or be in plaintext. Every cryptosystem involves a tradeoff between security and convenience, and ZFS encryption goes fairly hard toward convenience. In particular, Oracle decided that encrypted files must be deduplicatable. A necessary result is that they are trivially vulnerable to watermarking attacks. https://blogs.oracle.com/darren/entry/zfs_encryption_what_is_on > > I saw that Illumos has ZFS encrytion in the TODO list. > > -- > Florent Peterschmitt | Please: > flor...@peterschmitt.fr| * Avoid HTML/RTF in E-mail. > +33 (0)6 64 33 97 92 | * Send PDF for documents. > http://florent.peterschmitt.fr | * Trim your quotations. Really. > Proudly powered by Open Source | Thank you :) > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking
On Tue, Sep 3, 2013 at 9:42 AM, Jeremie Le Hen wrote: > On Mon, Sep 02, 2013 at 11:49:33AM +0300, Alexander Motin wrote: > > Hi. > > > > I would like to invite more people to review and test my patches for > > improving CAM and GEOM scalability, that for last six months you could > > see developing in project/camlock SVN branch. Full diff of that branch > > against present head (r255131) can be found here: > > http://people.freebsd.org/~mav/camlock_patches/camlock_20130902.patch > > I'm building my kernel right now. > > Can anyone confirm how well tested/stable this patch set might be?? if theres positive input i have a zoo of dev machines i could load it on, to help further it. Just checking to see how widely its been tested, > -- > Jeremie Le Hen > > Scientists say the world is made up of Protons, Neutrons and Electrons. > They forgot to mention Morons. > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage?
On Wednesday, August 28, 2013 12:40:15 pm Ivan Voras wrote: > On 28 August 2013 18:12, Gary Jennejohn wrote: > > > So, if I understand this correctly, a normal desktop user won't > > notice any real change, except that buildworld might get faster, > > and big servers will benefit? > > Basically, yes, but read on... > > > But could this negatively impact small, embedded systems, which > > usually have only small memory footprints? Although I suppose > > one could argue that they usually don't have large numbers of > > files cached in memory at any given time. > > Unless I'm wrong, the only pathological case coming from this change > would be the following sequence of events: > > 1) Memory is scarce [*] > 2) There's a sudden surge of requests for a huge number of different > directories > 3) There's an urgent lowmem event which is observed by dirhash, which > attempts to free memory but is prevented in doing so for the next 60 > seconds because all entries are young (the idea behind dirhash being > that if a directory is accessed, it will probably soon be accessed > again - think "ls" then "fopen", so we won't evict him until > reclaimage seconds) > 4) the kernel runs out of memory, game over. Just to play devil's advocate, the only way your change can benefit is if: 1) Memory is scarce thus triggering a lowmem event 2) There are requests for a huge number of directories that haven't been accessed in over 5 seconds. That is to say, what your change does is increase the relative importance of dirhash memory relative to other memory in the machine when the machine is under memory pressure. If the machine is not under memory pressure then the lowmem handler will not be triggered and your change will never matter. Keep in mind that if pagedaemon is able to keep up, the lowmem event handler will not be called. This handler only triggers when you are really low on memory and trying to allocate it faster than pagedaemon can reclaim free pages. In that sort of environment you generally want caches to return pages sooner rather than later. What would perhaps be better than a hardcoded reclaim age would be to use an LRU-type approach and perhaps set a target percent to reclaim. That is, suppose you were to reclaim the oldest 10% of hashes on each lowmem call (and make the '10%' the tunable value). Then you will always make some amount of progress in a low memory situation (and if the situation remains dire you will eventually empty the entire cache), but the effective maximum age will be more dynamic. Right now if you haven't touched UFS in 5 seconds it throws the entire thing out on the first lowmem event. The LRU-approach would only throw the oldest 10% out on the first call, but eventually throw it all out if the situation remains dire. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: About CPU cores numbering an processor affinity
On Friday, August 23, 2013 9:23:51 am Dmitry Sivachenko wrote: > Hello! > > I am using FreeBSD-9-STABLE on the following hardware: > > FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs > FreeBSD/SMP: 2 package(s) x 6 core(s) x 2 SMT threads > > So I have 2 physical CPUs with 6 core each. > > # cpuset -g > pid -1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23 > > > So each of 24 cores are numbered 0..23. > > 1) In what particular order are these cores numbered? Can I assume that 0..11 correspond to 1st physical CPU and 12..23 to second? How SMT threads are numbered within each core? Yes, the numbering is "grouped" so that you have each package as a contiguous block. Each core is a contiguous block as well, so SMT threads are adjacent to each other. > Should I use "-x" option of cpuset for that purpose (to bind irq 260 and 261 in my example)? Yes, cpuset -x. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
booting FreeBSD on Apple Mac mini with GPT disk partition
Does anyone know if work on booting FreeBSD on modern Apple hardware was ever completed? I have looked on the wiki, forums, and email archives but I don't see anything definitive. I would like to have a GPT partitioned disk with a freebsd-boot, freebsd-swap, and multiple freebsd-ufs partitions on a new Mac mini. Any pointers would be appreciated. Thanks, Kim -- Kim Shrier - k...@westryn.net Shrier and Deihl, Westryn Internet Services Internet Software Development and Hosting Remote Unix Admin, Security http://www.westryn.net/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking
On Tue, Sep 03, 2013 at 02:10:32PM -0400, Outback Dingo wrote: > On Tue, Sep 3, 2013 at 9:42 AM, Jeremie Le Hen wrote: > > > On Mon, Sep 02, 2013 at 11:49:33AM +0300, Alexander Motin wrote: > > > Hi. > > > > > > I would like to invite more people to review and test my patches for > > > improving CAM and GEOM scalability, that for last six months you could > > > see developing in project/camlock SVN branch. Full diff of that branch > > > against present head (r255131) can be found here: > > > http://people.freebsd.org/~mav/camlock_patches/camlock_20130902.patch > > > > I'm building my kernel right now. > > > > > Can anyone confirm how well tested/stable this patch set might be?? if > theres positive input i have a zoo of dev machines i could load it on, to > help further it. > Just checking to see how widely its been tested, Very stable so far. I'm doing a make -j 4 buildworld in parallel of a periodic security run. This has been running for hours without failure. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking
On Tue, Sep 3, 2013 at 8:10 PM, Outback Dingo wrote: > Can anyone confirm how well tested/stable this patch set might be?? if > theres positive input i have a zoo of dev machines i could load it on, to > help further it. > Just checking to see how widely its been tested, I've installed this patch on 3 differents machines there status after about 12hours: - SUN FIRE X4170 M2 (amd64: r255178) with 6 SAS harddrives in one big zraid (LSI MegaSAS Gen2 controller): Used for generating package with poudriere… no probleme since; - HAL/Fujitsu SPARC64-V (sparc64: r255178) with two SCSI-3 disks in gmirror: Used for generating package with poudriere too… no probleme since; - HP EliteBook 8460p (amd64: r255188) with DVD replaced by a second hardrive (where fbsd is installed): It crash just after the message "GEOM: new disk ada1" during boot screenshot of the crash screen: http://goo.gl/tW1VIx A little more information: addr2line -e /boot/kernel/kernel.symbols 0x8083abd3 /usr/src/sys/geom/geom_io.c:129 Regards, Olivier ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking
On Tue, Sep 3, 2013 at 5:48 PM, Olivier Cochard-Labbé wrote: > On Tue, Sep 3, 2013 at 8:10 PM, Outback Dingo > wrote: > > Can anyone confirm how well tested/stable this patch set might be?? if > > theres positive input i have a zoo of dev machines i could load it on, to > > help further it. > > Just checking to see how widely its been tested, > > I've installed this patch on 3 differents machines there status after > about 12hours: > - SUN FIRE X4170 M2 (amd64: r255178) with 6 SAS harddrives in one big > zraid (LSI MegaSAS Gen2 controller): Used for generating package with > poudriere… no probleme since; > - HAL/Fujitsu SPARC64-V (sparc64: r255178) with two SCSI-3 disks in > gmirror: Used for generating package with poudriere too… no probleme > since; > - HP EliteBook 8460p (amd64: r255188) with DVD replaced by a second > hardrive (where fbsd is installed): It crash just after the message > "GEOM: new disk ada1" during boot > > screenshot of the crash screen: > http://goo.gl/tW1VIx > > A little more information: > addr2line -e /boot/kernel/kernel.symbols 0x8083abd3 > /usr/src/sys/geom/geom_io.c:129 > > Regards, > > Olivier > Be nice if it was backported to 9/stable. not sure how feasible it is though... patch fails in a few places. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking
On Tue, Sep 03, 2013 at 11:24:26PM +0200, Jeremie Le Hen wrote: > On Tue, Sep 03, 2013 at 02:10:32PM -0400, Outback Dingo wrote: > > On Tue, Sep 3, 2013 at 9:42 AM, Jeremie Le Hen wrote: > > > > > On Mon, Sep 02, 2013 at 11:49:33AM +0300, Alexander Motin wrote: > > > > Hi. > > > > > > > > I would like to invite more people to review and test my patches for > > > > improving CAM and GEOM scalability, that for last six months you could > > > > see developing in project/camlock SVN branch. Full diff of that branch > > > > against present head (r255131) can be found here: > > > > http://people.freebsd.org/~mav/camlock_patches/camlock_20130902.patch > > > > > > I'm building my kernel right now. > > > > > > > > Can anyone confirm how well tested/stable this patch set might be?? if > > theres positive input i have a zoo of dev machines i could load it on, to > > help further it. > > Just checking to see how widely its been tested, > > Very stable so far. I'm doing a make -j 4 buildworld in parallel of a > periodic security run. This has been running for hours without failure. FWIW, I have 4 drives total, distributed in 2 zpool containing 2 mirrored zdev each. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
