Re: Heavy I/O blocks FreeBSD box for several seconds
In message <20110706170132.ga68...@troutmask.apl.washington.edu>, Steve Kargl w rites: >I periodically ran the same type test in the 2008 post over the >last three years. Nothing has changed. I even set up an account >on one node in my cluster for jeffr to use. He was too busy to >investigate at that time. Isn't this just the lemming-syncer hurling every dirty block over the cliff at the same time ? To find out: Run gstat and keep and eye on the leftmost column The road map for fixing that has been known for years... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Geom_gbde and Hardware Crypto Accelerators
In message <[EMAIL PROTECTED]>, Mike Tancsa writes: >On Tue, 5 Apr 2005 16:21:34 -0500, in sentex.lists.freebsd.questions >you wrote: > >>After searching google and the archives I wasn't able to find any >>current information on the status of hardware cryptographic >>accelerators (like the Soekris vpn1401) and gbde. Can gbde harness the >>power of one of these accelerator cards yet? If so do they provide >>significant offloading from the processor(s)? Any comments on the >>Soekris vpn1401 card I've been thinking about? Thanks in advance. > >Hi, > It wont work. I know the authorth was thinking about adding >VIA C3/Padlock support, but not sure the details. There is partial support for opencrypto/hifn/vpn1401 in the p4 branch phk_gbde, but it doesn't help very much because of the high setup overhead of the hifn chip. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gbde blackening feature - how can on disk keys be "destroyed" thoroughly?
In message <[EMAIL PROTECTED]>, David Kreil writes: > >Hi, > >>From what I can see so far, they are simply overwritten with zeros - is that >right? If so, the blackening feature would be much weakend, as once can read >up to 20 layers of data even under random data (and more under zeros). I would >be most grateful for comments, or suggestions of where/how one could extend >the code to do a secure wip of the key areas. Also, I know practically nothing >of how I could to best get FreeBSD to physically write to disk >(configurability of hardware cache etc permitting). On a modern disk there is no sequence of writes that will guarantee you that your data is iretriveable lost. Even if you rewrite a thousand times, you cannot guard yourself against the sector being replaced by a bad block spare after the first write. If your threat-analysis indicates this is a serious threat for you, you should arrange for simple physical destruction of your disk to be available. Most modern disks have one or more holes in the metal only covered by a metalic sticker. Pouring sulfuric acid through those openings is a good start. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gbde blackening feature - how can on disk keys be "destroyed" thoroughly?
In message <[EMAIL PROTECTED]>, David Kreil writes: >> On a modern disk there is no sequence of writes that will guarantee >> you that your data is iretriveable lost. >> Even if you rewrite a thousand times, you cannot guard yourself against >> the sector being replaced by a bad block spare after the first write. > >Good point. In the rare chance event that this happens, it would indeed be bad >news as an attacker would then only have to scan the bad blocks for possible >copies of the key. He still has no way of recognizing the key though... >A simple improvement on the present situation would already be if >the keys were not overwritten with zeros but with random bits. I >don't know how difficult it would be to attempt to physically write >random bits multiple times but it would much strengthen the feature >apart from the rare cases when the sectors of the masterkey have >been remapped into bad blocks. Please read the paper, there is a reason why it is zero bits. >What do you think? Is the required effort disproportional to the >intended value of the blackening feature? Blackening adds no significant incremental security imo, on the other hand it is feasible to implement it, so I've put it on the todo list. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck on a read only partition?
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: >Hello, how do I fsck my disk if it's mounted? > >I have downgraded the mount to read-only, but still geom seems >to disallow fsck access to it. > >Is there a way to tell the system to allow fsck to open it >read/write? Not apart from the dreaded debug option. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dmesg showing wrong frequency (IBM T30)
In message <[EMAIL PROTECTED]>, Tobias Roth writes: >Hi > >On my IBM T30 1.8GHz, dmesg (with both 4.8 and 5.1) shows me this line: > >CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.8GHz (1196.13-MHz 686-class CPU) > >Various windows utilities also claim that the cpu identification string >marks my cpu as 1.8 GHz unit, while the maximum frequency always gets >detected as something just below 1.2GHz. > >What is wrong here? To other IBM T30 users: Is your CPU identification >correct? What's "wrong" here is that the BIOS/ACPI firmware in your laptop runs your CPU at a reduced rate in order to make the battery last longer. Manufactureres have taken great care to not make it clear that the specs they give you are all reachable, _just_not_at_the_same_time_. You may be able to twiddle things in the BIOS or using ACPI and get faster CPU but less battery lifetime. It can also be that the case that the "cooling solution" (ie: fans, fins etc) does not work well enough and the ACPI code has slowed down the CPU in order to not melt anything [*]. In particular our ACPI code does not seem to always start fans when they should due to high temperatures. Poul-Henning [*] Known in certain circles as a "Warnering your laptop" :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bootstrap: Machine keeps booting ? (boot0/mbr) ?
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: >I have exactly the same problem. I'm assuming that this was caused by >the changes committed by PHK. See the [HEADSDOWN] swap_pager.c calming down >and the Weird reboots from bootmgr or loader threads. He is looking at >it now and will probably be committing a fix. Already committed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FW: 20TB Storage System
In message <[EMAIL PROTECTED]>, "Max Clark" writ es: >Given the above: >1) What would my expected IO be using vinum to stripe the storage enclosures >detailed above? That depends a lot on the applications I/O pattern, an I doubt a precise prediction is possible. In particular the FibreChannel is hard to predict the throughput off because the various implementations seems to have each their own peculiar quirks performance wise. On a SEAGATE ST318452 disks, I see sequential transfer rates at the outside rim of the disk of 58MB/sec. If I stripe two of them them with CCD I get 107MB/sec. CCD has a better performance than Vinum where they compare. RAID-5 and striping a large number of disks does not scale linearly performance wise, in particular you _may_ see your average access time drop somewhat, but there is by far no guarantee that it will be better than the individual drive. >2) What is the maximum size of a filesystem that I can present to the host >OS using vinum/ccd? Am I limited anywhere that I am not aware of? Good question, I'm not sure we currently know the exact barrier. >3) Could I put all 20TB on one system, or will I need two to sustain the IO >required? Spreading it will give you more I/O bandwidth. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FW: 20TB Storage System
In message <[EMAIL PROTECTED]>, "Max Clark" writ es: >I know adding ccd/vinum to the equation will lower my IO throughput, but the >question is... if I have an external hardware shelf with 3.5TB (16 250GB >drives w/ Raid 5 from hardware) and I put a Raid 0 stripe across 3 of these >shelves what would my expected loss of IO be? The loss will mostly be from latency, but how much is impossible to tell I think. The statistics of this, even with my trusty old Erlang table would still be too uncertain to be of any value. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 20TB Storage System
In message <[EMAIL PROTECTED]>, Petri Helenius writes: >fsck problem should be gone with less inodes and less blocks since if >I read the code correctly, memory is consumed according to used inodes >and blocks so having like 2 inodes and 64k blocks should allow >you to build 5-20T filesystem and actually fsck them. I am not sure I would advocate 64k blocks yet. I tend to stick with 32k block, 4k fragment myself. This is a problem which is in the cross-hairs for 6.x -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 20TB Storage System
In message <[EMAIL PROTECTED]>, Petri Helenius writes: >You have any insight into the fsck memory consumption? I remember getting >myself saved quite a long time ago by reducing the number of inodes. I have not studied it. I always try to avoid having more than an order of magnitude more inodes than I need, it also saves fsck time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 20TB Storage System
In message <[EMAIL PROTECTED]>, David Gilbert writes: >That reminds me... has anyone thought of designing the system to have >more than 8 frags per block? Increasingly, for large file >performance, we're pushing up the block size dramatically. This is >with the assumption that large disks will contain large files. > >It strikes me that driving the block size up (as far as 1M) and having >a 256 (or so) fragments might become appropriate. Sounds like a _great_ project for somebody :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
