2. Dan Kaminsky released Phreebird which includes Phreeload which is a library on top of OpenSSL to verify certificate fingerprints using DNSSEC and a TXT-record.
Yes, a higher load, but the load will only be increased by a very, very small marinal number. Just have a look at what the Google study had to say about it.
With the right extension we could even speed up loading of the webpages:
Because HTTP does not currently do multiplexing of multiple streams over the same TCP (or TCP/SSL) connection. The only solution that is has is to open several connections and because we need to use TCP-slowstart it can't utilize the available bandwidth.
Their is also a bug in Chrome when you start up it will connect to the google.com-domain to check for updates and do so over HTTP and the problem with this is, it will also send the normal cookies associated with google.com. Which might give the attacker enough information to get into your igoogle/gmail account.
Chrome does support SNI on Windows XP, they still use the same Windows certificate store, but I don't know if they hacked around the Windows library or just use a different library.
Don't use passwords, use OpenID ? I guess you can still hijack sessionids, so that is useless.
But SSL/TLS isn't perfect either. Any root-CA or sub-CA can issue any certificate.
We would atleast still need something like DNSSEC to validate what is stored in DNS. So that we can store in DNS, not just the A- or AAAA-record, but also which CA is allowed to sign your certificates.
Even then, if you choose an external CA, it has pretty much been proven that governments can still get certificates from them.
Do you trust the government of the country where you get your certificates from ?
For the next couple of years, without a DNSSEC-validating client in the browser and some protocols to support it, we are pretty much fucked.
But I do know at that speed, you possible don't want to add block deduplication, you need a lot of memory for that and CPU is probably already taxed. Just look at the thread about btrfs on the mailinglist, you will see that just doing checksums has to be done the right way just to keep up.
I think the -o nodatasum option actually disables the checksums, so that should tell you that the CPU's are probably already the bottleneck.
I think it is just a matter of time before some of these things will be implemented and btrfs is considered stable. The cool thing about btrfs is is, most of the features are added to the Linux kernel itself, it just is btrfs is one of the many users of that infrastructure. So other (future ?) filesystems can make of it as well.
I read somewhere that the btrfs b-tree is newer and thus possible even more suitable for filesystems like this. If that is true, maybe btrfs could end up at the top.
Here is some more info about a recent company using ZFS for their needs:
I was immediately thinking if that would mean someone could make a cheaper NetFPGA/LibreRouter (line rate forwarding open source router platform using FPGA instead of ASICs which the normal routers from Cisco, Juniper, etc. use for hardware-routing/switching).
It is mostly used for academic purposes, but if the FPGA does not have direct access to RAM and can not do direct I/O it's probably not useful.
OK, maybe I should add that after some tuning it got much better:
Reference figures: 16* single disk (theoretical limit): 4092 MiByte/s fio data layer tests (achievable limit): 3250 MiByte/s ZFS performance: 2505 MiByte/s
BtrFS figures: IOzone on 2.6.32: 919 MiByte/s fio btrfs tests on 2.6.35: 1460 MiByte/s IOzone on 2.6.35 with crc32c: 1250 MiByte/s IOzone on 2.6.35 with crc32c_intel: 1629 MiByte/s IOzone on 2.6.35, using -o nodatasum: 1955 MiByte/s
OK, I should add, after some changes/tuning he got:
Reference figures: 16* single disk (theoretical limit): 4092 MiByte/s fio data layer tests (achievable limit): 3250 MiByte/s ZFS performance: 2505 MiByte/s
BtrFS figures: IOzone on 2.6.32: 919 MiByte/s fio btrfs tests on 2.6.35: 1460 MiByte/s IOzone on 2.6.35 with crc32c: 1250 MiByte/s IOzone on 2.6.35 with crc32c_intel: 1629 MiByte/s IOzone on 2.6.35, using -o nodatasum: 1955 MiByte/s
You can use it just fine. It can just not be included in the kernel.
If I understand it correctly, it is the same situation we had with qmail before it became public domain.
When you are installing a new server/installation (or have a central repository), you would have to do a compile from source. Because no1 can bundle the 2 for distribution.
They did actually benchmark openindiana as well, which includes the lastest version of ZFS which is available through open source.
Which was faster in some tests and slower in some other tests. It was mostly slower in tests that did include openindiana, but we don't know how it performed in the others. So the test was kind of useless.
Phoronix tested with a single HHD and did tests with a single SSD.
I do however think that the important lesson here is, that from the few people who tested it, on large installations (a large number of SSDs), ZFS/FreeBSD is faster then btrfs/Linux. For example, from Aug 05 2010:
Slashdot Mirror
So far I've not seen anyone implement any specification. This is the only real effort so far:
1. http://www.imperialviolet.org/2010/08/16/dnssectls.html
2. Dan Kaminsky released Phreebird which includes Phreeload which is a library on top of OpenSSL to verify certificate fingerprints using DNSSEC and a TXT-record.
I don't know and who validates the response from the Perspectives notaries (the agents in the networks which store this information) ?
And what about my privacy ? Do they store the information about the sites I visit (they probably say they don't).
Maybe Certificate Patrol is a good start:
https://addons.mozilla.org/en-US/firefox/addon/6415/
It works like SSH, everytime you connect it will tell you if something changed since you last connected. It also will tell you what changed.
DNSSEC is the solution for that, but it will take years before we'll have validating resolves in the browser.
In studies it has been shows, even many DSL-routers block DNS over TCP or large DNS-packets.
Yes, a higher load, but the load will only be increased by a very, very small marinal number. Just have a look at what the Google study had to say about it.
With the right extension we could even speed up loading of the webpages:
http://www.chromium.org/spdy/spdy-whitepaper
Because HTTP does not currently do multiplexing of multiple streams over the same TCP (or TCP/SSL) connection. The only solution that is has is to open several connections and because we need to use TCP-slowstart it can't utilize the available bandwidth.
Their is also a bug in Chrome when you start up it will connect to the google.com-domain to check for updates and do so over HTTP and the problem with this is, it will also send the normal cookies associated with google.com. Which might give the attacker enough information to get into your igoogle/gmail account.
Chrome does support SNI on Windows XP, they still use the same Windows certificate store, but I don't know if they hacked around the Windows library or just use a different library.
Don't use passwords, use OpenID ? I guess you can still hijack sessionids, so that is useless.
But SSL/TLS isn't perfect either. Any root-CA or sub-CA can issue any certificate.
We would atleast still need something like DNSSEC to validate what is stored in DNS. So that we can store in DNS, not just the A- or AAAA-record, but also which CA is allowed to sign your certificates.
Even then, if you choose an external CA, it has pretty much been proven that governments can still get certificates from them.
Do you trust the government of the country where you get your certificates from ?
For the next couple of years, without a DNSSEC-validating client in the browser and some protocols to support it, we are pretty much fucked.
I guess I mean socket.
I just want to know if it has an RJ45-connector. :-)
But this has effects from Enlightenment, which makes it so much better. :-)
It's E17 actually.
No ARC and no L2ARC and no ZIL I think.
But I do know at that speed, you possible don't want to add block deduplication, you need a lot of memory for that and CPU is probably already taxed. Just look at the thread about btrfs on the mailinglist, you will see that just doing checksums has to be done the right way just to keep up.
I think the -o nodatasum option actually disables the checksums, so that should tell you that the CPU's are probably already the bottleneck.
I think it is just a matter of time before some of these things will be implemented and btrfs is considered stable. The cool thing about btrfs is is, most of the features are added to the Linux kernel itself, it just is btrfs is one of the many users of that infrastructure. So other (future ?) filesystems can make of it as well.
I read somewhere that the btrfs b-tree is newer and thus possible even more suitable for filesystems like this. If that is true, maybe btrfs could end up at the top.
Here is some more info about a recent company using ZFS for their needs:
http://www.anandtech.com/show/3963/zfs-building-testing-and-benchmarking
http://www.zfsbuild.com/
I was immediately thinking if that would mean someone could make a cheaper NetFPGA/LibreRouter (line rate forwarding open source router platform using FPGA instead of ASICs which the normal routers from Cisco, Juniper, etc. use for hardware-routing/switching).
It is mostly used for academic purposes, but if the FPGA does not have direct access to RAM and can not do direct I/O it's probably not useful.
What makes Java so special for this field ? Or is just existing software ? Or available services ?
OK, maybe I should add that after some tuning it got much better:
Reference figures:
16* single disk (theoretical limit): 4092 MiByte/s
fio data layer tests (achievable limit): 3250 MiByte/s
ZFS performance: 2505 MiByte/s
BtrFS figures:
IOzone on 2.6.32: 919 MiByte/s
fio btrfs tests on 2.6.35: 1460 MiByte/s
IOzone on 2.6.35 with crc32c: 1250 MiByte/s
IOzone on 2.6.35 with crc32c_intel: 1629 MiByte/s
IOzone on 2.6.35, using -o nodatasum: 1955 MiByte/s
OK, I should add, after some changes/tuning he got:
Reference figures:
16* single disk (theoretical limit): 4092 MiByte/s
fio data layer tests (achievable limit): 3250 MiByte/s
ZFS performance: 2505 MiByte/s
BtrFS figures:
IOzone on 2.6.32: 919 MiByte/s
fio btrfs tests on 2.6.35: 1460 MiByte/s
IOzone on 2.6.35 with crc32c: 1250 MiByte/s
IOzone on 2.6.35 with crc32c_intel: 1629 MiByte/s
IOzone on 2.6.35, using -o nodatasum: 1955 MiByte/s
ZFS port for Linux is beta, btrfs is beta everywhere. I think it is kind of fair.
You can use it just fine. It can just not be included in the kernel.
If I understand it correctly, it is the same situation we had with qmail before it became public domain.
When you are installing a new server/installation (or have a central repository), you would have to do a compile from source. Because no1 can bundle the 2 for distribution.
But I'm not a lawyer.
Data loss because God targets you ? That is what the off-site back up is for right ?
How about 16 SSD's ?:
ZFS BtrFS
1 SSD 256 MiByte/s 256 MiByte/s
2 SSDs 505 MiByte/s 504 MiByte/s
3 SSDs 736 MiByte/s 756 MiByte/s
4 SSDs 952 MiByte/s 916 MiByte/s
5 SSDs 1226 MiByte/s 986 MiByte/s
6 SSDs 1450 MiByte/s 978 MiByte/s
8 SSDs 1653 MiByte/s 932 MiByte/s
16 SSDs 2750 MiByte/s 919 MiByte/s
http://marc.info/?l=linux-btrfs&m=128101763830740&w=2
They did actually benchmark openindiana as well, which includes the lastest version of ZFS which is available through open source.
Which was faster in some tests and slower in some other tests. It was mostly slower in tests that did include openindiana, but we don't know how it performed in the others. So the test was kind of useless.
Phoronix tested with a single HHD and did tests with a single SSD.
I do however think that the important lesson here is, that from the few people who tested it, on large installations (a large number of SSDs), ZFS/FreeBSD is faster then btrfs/Linux. For example, from Aug 05 2010:
ZFS BtrFS
1 SSD 256 MiByte/s 256 MiByte/s
2 SSDs 505 MiByte/s 504 MiByte/s
3 SSDs 736 MiByte/s 756 MiByte/s
4 SSDs 952 MiByte/s 916 MiByte/s
5 SSDs 1226 MiByte/s 986 MiByte/s
6 SSDs 1450 MiByte/s 978 MiByte/s
8 SSDs 1653 MiByte/s 932 MiByte/s
16 SSDs 2750 MiByte/s 919 MiByte/s
http://marc.info/?l=linux-btrfs&m=128101763830740&w=2
By that time FS-Cache (general "L2ARC" for Linux: http://lwn.net/Articles/312708/ ) will be in the kernel. And maybe btrfs will be considered stable.
Some say the b-tree variant in btrfs is smarted then the one that was used in ZFS.
I guess time will tell.
"* Integral iSCSI provider. Nice to have with the above feature!"
This is not a function of ZFS but OpenSolaris, Linux is can act as a iSCSI target as well.
"The OS, your DBMS, or even the drive itself will probably read and cache the surrounding bytes, so there will probably be no additional IO latency."
IF it is located nearby, it will help, but that obviously isn't always true. Maybe not even true many times.
On Twitter he mentioned they'll continue the work on Mono.
"After the Novell acquisition, Mono continues as-is, but our paychecks will come from Attachmate instead of Novell."