Re: ATA Security patch to atacontrol
Jeremy Chadwick wrote: Can you provide me datasheet and technical reference material to what "ATA Security" is? Which ATA specification is this documented in? I'd like to read it. I think you can found it in ATA-ATAPI-7 vol.1: "4.7 Security Mode feature set". http://en.wikipedia.org/wiki/Advanced_Technology_Attachment#HDD_Passwords_and_Security http://en.wikipedia.org/wiki/Advanced_Technology_Attachment#ATA_standards_versions.2C_transfer_rates.2C_and_features -- WBR, Andrey V. Elsukov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SSH Brute Force attempts
Jeremy Chadwick wrote: You naturally have to keep pf.conf.ssh-* in sync if you have multiple machines. You can use pfsync(4) to accomplish this task (I think), or you can do it the obvious way (make a central distribution box that scp/rsync's the files out and runs "/etc/rc.d/pf reload"). pfsync sychronises the dynamic state sessions between machines -- ie. basically what you see by doing 'pfctl -ss' It doesn't as far as I know synchronise table contents even if the table changes are themselves dynamically generated in response to traffic. rsync is your friend here. As for blocking based on geographical source of IPs -- I see where you're coming from, but you've missed out one of the largest territories that is the source of this sort of thing, namely the USA. The best strategy IMHO is to foil the automated password guessers but not using passwords. SSH key based auth works nicely, is easy to setup and use and is unfeasible to break by trial and error across a remote network connection. Using firewall blocking on top of this is still useful (to reduce the noise in the log files and stop system resources being sucked up by SSH's crypto requirements) but it shouldn't be a necessity. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: SSH Brute Force attempts
On Monday 29 September 2008, Rich Healey <[EMAIL PROTECTED]> sent a
missive stating:
> Recently I'm getting a lot of brute force attempts on my server, in the
> past I've used various tips and tricks with linux boxes but many of them
> were fairly linux specific.
>
> What do you BSD guys use for this purpose?
>
> If this belongs on -security let me know and I'll ask over there.
>
> Cheers
>
>
> Rich
Yeap, -security
However, also try this in pf.conf (specific rules related to this; you'll need
more for a real pf.conf):
table { } persist
block in quick from
pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state
(max-src-conn 5, max-src-conn-rate 4/300, overload flush global)
This will add "badguys" to the table if they connect more then 4 times in 300
seconds.
Then use the expiretables port from a cronjob to remove IPs if you feel like
it.
Henrik
--
Henrik Hudson
[EMAIL PROTECTED]
--
"There are 10 kinds of people in the world: Those who
understand binary and those who don't..."
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SSH Brute Force attempts
Rich Healey said the following on 9/29/08 8:10 PM: > Recently I'm getting a lot of brute force attempts on my server, in the > past I've used various tips and tricks with linux boxes but many of them > were fairly linux specific. > > What do you BSD guys use for this purpose? > > If this belongs on -security let me know and I'll ask over there. Hi Rich! I use DenyHosts (/usr/ports/security/denyhosts) and it works great.. :) Best, --Glenn -- ...destination is merely a byproduct of the journey --Eric Hansen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SSH Brute Force attempts
Rich Healey <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Recently I'm getting a lot of brute force attempts on my server, in the > past I've used various tips and tricks with linux boxes but many of them > were fairly linux specific. > > What do you BSD guys use for this purpose? > > If this belongs on -security let me know and I'll ask over there. http://potentialtech.com/cms/node/16 -- Bill Moran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SSH Brute Force attempts
On Tue, Sep 30, 2008 at 10:10:59AM +1000, Rich Healey wrote: > Recently I'm getting a lot of brute force attempts on my server, in the > past I've used various tips and tricks with linux boxes but many of them > were fairly linux specific. > > What do you BSD guys use for this purpose? This probably should've gone to -security, correct. There are 3 ports which people often use for solving this: ports/security/blocksshd ports/security/sshblock ports/security/sshguard-(pf|ipfw|ipfilter) The latter depends on which firewalling stack you use, and I believe one of the other two only work with ipfw (I forget which). I have great reservations using any of these, because they dynamically add firewalling rules/tables to your machines based on data in log files. For me, it smells of an accident waiting to happen. I'm an advocate of simply blocking large netblocks where most of these attacks come from (Latin America, eastern Europe, Asia, and Russia). This requires that you appropriately tune things over time, and *be intelligent* about what you're doing. :-) What we use in our pf.conf on our production systems: table persist file "/conf/ME/pf.conf.ssh-allow" table persist file "/conf/ME/pf.conf.ssh-deny" block in on $ext_if proto tcp from to any port ssh pass in on $ext_if proto tcp from to any port ssh flags S/SA keep state pf.conf.ssh-deny contains a list of IPs or CIDRs which are to be blocked. I can provide this file if desired. pf.conf.ssh-allow contains a list of IPs or CIDRs which "override" blocks in the previous "block" rule. The reason we have this is due to one Russian user who wasn't able to SSH into our boxes due to the previous block rule. You naturally have to keep pf.conf.ssh-* in sync if you have multiple machines. You can use pfsync(4) to accomplish this task (I think), or you can do it the obvious way (make a central distribution box that scp/rsync's the files out and runs "/etc/rc.d/pf reload"). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SSH Brute Force attempts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Recently I'm getting a lot of brute force attempts on my server, in the past I've used various tips and tricks with linux boxes but many of them were fairly linux specific. What do you BSD guys use for this purpose? If this belongs on -security let me know and I'll ask over there. Cheers Rich - -- Rich Healey - iTReign \.''`. / [EMAIL PROTECTED] Developer / Systems Admin \ : :' : /[EMAIL PROTECTED] AIM: richohealey33 \ `. `' / [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] \ `- / [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjhbpMACgkQLeTfO4yBSAf36QCdE2cI75OAmyODre33sPPMrA8j 3VYAn3aHl1w5qyynd4rfYuxxqI6b2tAF =plT2 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA Security patch to atacontrol
On Tue, Sep 30, 2008 at 01:06:55AM +0200, Daniel Roethlisberger wrote: > I've added experimental support for the ATA Security command set to > atacontrol. Please test and review. If you have some spare disk(s) > with ATA Security support and a BIOS which does not freeze the security > configuration, I'd like to hear about any results of playing with this > patch. See the changes to the manual page for details on the commands. > > Note that you may render disks unusable using the ATA Security commands. > Use with great care. > > http://daniel.roe.ch/code/ata/atasecurity-20080930-complete.diff Daniel, Can you provide me datasheet and technical reference material to what "ATA Security" is? Which ATA specification is this documented in? I'd like to read it. Thanks! -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ATA Security patch to atacontrol
I've added experimental support for the ATA Security command set to atacontrol. Please test and review. If you have some spare disk(s) with ATA Security support and a BIOS which does not freeze the security configuration, I'd like to hear about any results of playing with this patch. See the changes to the manual page for details on the commands. Note that you may render disks unusable using the ATA Security commands. Use with great care. http://daniel.roe.ch/code/ata/atasecurity-20080930-complete.diff -- Daniel Roethlisberger http://daniel.roe.ch/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: priority fields in a thread
On Friday 26 September 2008 07:15:48 pm Murty, Ravi wrote: > Hello, > > I was wondering what all these different priority related fields in a > thread structure meant. This is the 8.0 kernel tree. > > Td_base_pri What the thread's priority should be while it is in the kernel. Doing a *sleep(..., PFOO) sets this to PFOO. On return to userland it gets set back to td_user_pri. The purpose of this field is to hold the "real" priority of a thread and is used when undoing the effects of priority propagation. > Td_user_pri This is the user priority of the thread. This is always >= PZERO for normal processes (real-time processes are different, though). When exiting the kernel, any priority "boost" from *sleep() is given up by dropping the priority back to this value. > Td_base_user_pri This is like td_base_pri in that it is a saved copy of the "real" userland priority of a thread. The umtx locks now support a userland version of priority propagation and this field is used to restore the user priority of a thread when it drops the locks other user threads need. > Td_priority This is the actual priority of the thread right now. When the thread is in userland, this should equal td_user_pri. When the thread is in the kernel, this should equal td_base_pri except for when the thread has been lent another thread's priority because it holds a lock that other thread needs. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: atacontrol broken in 7.1-PR
Again I would like to extend my thanks to everyone who helped with this problem, and a special thank you Jeremy and Bruce for trying to sus out where the fault might be. Your input and support is deeply appreciated. Peg > -Original Message- > From: Dag-Erling Smørgrav [mailto:[EMAIL PROTECTED] > Sent: 29 September 2008 16:01 > To: Poul-Henning Kamp > Cc: Bruce Cran; freebsd-hackers@freebsd.org; Andrey V. Elsukov; Pegasus > McCleaft > Subject: Re: atacontrol broken in 7.1-PR > > Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > > I'll take care of it. > > kib beat me to it... > > DES > -- > Dag-Erling Smørgrav - [EMAIL PROTECTED] > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.169 / Virus Database: 270.7.4/1695 - Release Date: > 29/09/2008 07:40 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: atacontrol broken in 7.1-PR
Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > I'll take care of it. kib beat me to it... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: atacontrol broken in 7.1-PR
On Mon, Sep 29, 2008 at 04:19:43PM +0200, Dag-Erling Smørgrav wrote: > Jeremy Chadwick <[EMAIL PROTECTED]> writes: > > I see the system has an Intel AHCI-based controller (probably an ICH10 > > chip, since the ICH10 is the first to support 6 SATA channels). > > No. I have an ICH8 with six channels, of which five are in use. Thanks for the clarification. The breakdown is as follows: ICH7= 4 ports ICH7R = 6 ports ICH7DH = 6 ports ICH7M = unknown ICH7MDH = unknown ICH7U = unknown ICH8= 4 ports ICH8R = 6 ports ICH8DH = 6 ports ICH8DO = 6 ports ICH8M = 3 ports ICH8ME = 3 ports ICH9= 4 ports ICH9R = 4 ports ICH9DH = 4 ports ICH9DO = 4 ports ICH9M = unknown ICH9ME = unknown ICH10 = 6 ports ICH10R = 6 ports -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: atacontrol broken in 7.1-PR
"Poul-Henning Kamp" <[EMAIL PROTECTED]> writes: > "Andrey V. Elsukov" <[EMAIL PROTECTED]> writes: > > Hi, Poul-Henning, I think it should be MFCed before release. > I agree, but I'm ENOTIME. I'll take care of it. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: atacontrol broken in 7.1-PR
Jeremy Chadwick <[EMAIL PROTECTED]> writes: > I see the system has an Intel AHCI-based controller (probably an ICH10 > chip, since the ICH10 is the first to support 6 SATA channels). No. I have an ICH8 with six channels, of which five are in use. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: experimantal question about md's
Hello @all, hello Oliver, thnak you for your reply. No i do not try to solve a real problem. It was hypothetically, an idea, not more not less. I have this written in my first posting. And for me, it is a logical dependency that the ram get paged to the swap if there is not enough RAM for all processes and in-memory data. I think my question is answered good enough. Thanks for all. greetings Michael 2008/9/29 Oliver Fromme <[EMAIL PROTECTED]> > Michael Schuh wrote: > > Clearly the Writeprocess of writeing data to an mirror is totally ended, > as > > all mirrordevices are written. > > But for the read the kernel uses the faster device..and there it > could > > be an advantage.i m thinking. > > And yes i think it could be an advantage, if the RAMed mirror is very > fast, > > we have only to wait > > for the first initialization, all the ongoing reads go to the ramdisk, > all > > writes goes to both devices. > > I think it would be completely sufficient to use a normal > device and let the kernel cache the data. This is much > better because the kernel dynamically adapts the cache > size to the workload and memory requirements. > > If you use an unusual asymmetric mirror setupt with a > physical disk and a memory disk (swap-backed), the machine > will have to start paging as soon as the requirements of > your processes grow beyond what's available. This will > be very slow, of course. > > For example (a little bit simplified): Say there's a spike > in web accesses so you get many processes that want to > allocate memory. If you run out of free memory, the kernel > will drop some pages that contain cached data and re-use > them. If the cached data is used later, the kernel will > re-read it from the disk. On the other hand, if you use > a memory disk, you effectively reduce the amount of memory > available by the size of that disk. If a process wants > to allocate memory now, the kernel can't simply drop any > pages used by the memory disk -- it has to write them to > the swap area first. It is obvious that the performance > is worse. > > And of course, the kernel will still try to cache the file > system data (the VFS code doesn't care that the file system > is on a gmirror with one half on a memory disk). So the > cache and the memory disk fight for RAM at the same time. > Basically you would be wasting RAM and losing performance. > > > if i have enough ram in the box, it is possible to say: Hi kernel use > plase > > 8 Gigs of ram for buffering > > the directory abc on the disk directaccesABC ??? i think not. > > The kernel will basically use all available RAM for > caching and buffering. This works especially well for > static web content. There are a few sysctl variables > to influence the behaviour, but it's usually better not > to touch them. > > I get the impression that you're trying to solve a problem > that doesn't exist. If you think you _do_ have a problem, > please provide some evidence, such as output from iostat, > gstat, vmstat and so on. > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- > chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > "C++ is to C as Lung Cancer is to Lung." >-- Thomas Funke > -- === m i c h a e l - s c h u h . n e t === Michael Schuh Postfach 10 21 52 66021 Saarbrücken phone: 0681/8319664 mobil: 0177/9738644 @: m i c h a e l . s c h u h @ g m a i l . c o m === Ust-ID: DE251072318 === ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: experimantal question about md's
On Mon, 29 Sep 2008 10:36:46 +0200 "Michael Schuh" <[EMAIL PROTECTED]> wrote: > so we have a webserver (par example) at this mirror it has very good > speed for the file-access > (ok i know in allmost cases is not the disk the bottleneck, and if we > could doing caching...) > at the above examle it is not really important if the write process > needs a second or two longer, > but by millions of requests it could be interseting to read the data > very fast.. That's exactly the case in which caching will work best. FreeBSD's integrated cache/VM system would keep such pages in memory even at the expense of writing other user data to swap. When I suggested a swap-backed device I was forgetting that malloc backed devices use memory that won't be paged, so there may be an advantage, but I think it would be the opposite to what you want. What it would do is keep rarely used file data in memory even if there's a better use for the memory elsewhere, so you would be trading performance for better worst-case latency. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: experimantal question about md's
Michael Schuh wrote: > Clearly the Writeprocess of writeing data to an mirror is totally ended, as > all mirrordevices are written. > But for the read the kernel uses the faster device..and there it could > be an advantage.i m thinking. > And yes i think it could be an advantage, if the RAMed mirror is very fast, > we have only to wait > for the first initialization, all the ongoing reads go to the ramdisk, all > writes goes to both devices. I think it would be completely sufficient to use a normal device and let the kernel cache the data. This is much better because the kernel dynamically adapts the cache size to the workload and memory requirements. If you use an unusual asymmetric mirror setupt with a physical disk and a memory disk (swap-backed), the machine will have to start paging as soon as the requirements of your processes grow beyond what's available. This will be very slow, of course. For example (a little bit simplified): Say there's a spike in web accesses so you get many processes that want to allocate memory. If you run out of free memory, the kernel will drop some pages that contain cached data and re-use them. If the cached data is used later, the kernel will re-read it from the disk. On the other hand, if you use a memory disk, you effectively reduce the amount of memory available by the size of that disk. If a process wants to allocate memory now, the kernel can't simply drop any pages used by the memory disk -- it has to write them to the swap area first. It is obvious that the performance is worse. And of course, the kernel will still try to cache the file system data (the VFS code doesn't care that the file system is on a gmirror with one half on a memory disk). So the cache and the memory disk fight for RAM at the same time. Basically you would be wasting RAM and losing performance. > if i have enough ram in the box, it is possible to say: Hi kernel use plase > 8 Gigs of ram for buffering > the directory abc on the disk directaccesABC ??? i think not. The kernel will basically use all available RAM for caching and buffering. This works especially well for static web content. There are a few sysctl variables to influence the behaviour, but it's usually better not to touch them. I get the impression that you're trying to solve a problem that doesn't exist. If you think you _do_ have a problem, please provide some evidence, such as output from iostat, gstat, vmstat and so on. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is to C as Lung Cancer is to Lung." -- Thomas Funke ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bad NFS/UDP performance
On Mon, 29 Sep 2008, Oliver Fromme wrote: Danny Braniss wrote: > Grr, there goes binary search theory out of the window, > So far I have managed to pinpoint the day that the changes affect the > throughput: > 18/08/08 00:00:00 19/08/08 00:00:00 > (I assume cvs's date is GMT). > now would be a good time for some help, specially how to undo changes, my > knowledge of csup/cvs are close to zero. So you've nailed to down to this 24-hour window: http://www.secnetix.de/olli/FreeBSD/svnews/?day=2008-08-18&p=/stable/7 I'm afraid that r181822 by rwatson is the most likely candidate that might be causing the regression. If we can confirm that it was that specific change, then I can create a patch to restore exclusive locking for UDP and we can see if it was the general move to rwlocking, or specifically the read-locking of certain data structures. Perhaps what we've done is moved contention from a mutex to a sleep lock, reducing the efficiency of handling contention? Adding Kris to the CC line because he often has useful insights on this sort of thing. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bad NFS/UDP performance
Danny Braniss wrote: > Grr, there goes binary search theory out of the window, > So far I have managed to pinpoint the day that the changes affect the > throughput: > 18/08/08 00:00:00 19/08/08 00:00:00 > (I assume cvs's date is GMT). > now would be a good time for some help, specially how to undo changes, my > knowledge of csup/cvs are close to zero. So you've nailed to down to this 24-hour window: http://www.secnetix.de/olli/FreeBSD/svnews/?day=2008-08-18&p=/stable/7 I'm afraid that r181822 by rwatson is the most likely candidate that might be causing the regression. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C is quirky, flawed, and an enormous success." -- Dennis M. Ritchie. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: experimantal question about md's
Hi, thank you for your answer. Clearly the Writeprocess of writeing data to an mirror is totally ended, as all mirrordevices are written. But for the read the kernel uses the faster device..and there it could be an advantage.i m thinking. And yes i think it could be an advantage, if the RAMed mirror is very fast, we have only to wait for the first initialization, all the ongoing reads go to the ramdisk, all writes goes to both devices. so we have a webserver (par example) at this mirror it has very good speed for the file-access (ok i know in allmost cases is not the disk the bottleneck, and if we could doing caching...) at the above examle it is not really important if the write process needs a second or two longer, but by millions of requests it could be interseting to read the data very fast.. in my idea it was only focused on reads not on writes, the drawbacks of Raid are well known if i have enough ram in the box, it is possible to say: Hi kernel use plase 8 Gigs of ram for buffering the directory abc on the disk directaccesABC ??? i think not. in the case of my idea it is clearly. but on the other side we need to have to say: Hi kernel, do never ever buffering on this rambased Diskdevice or we shoot us in our kneesas i think thank you michael 2008/9/29 Zaphod Beeblebrox <[EMAIL PROTECTED]> > > > On Fri, Sep 26, 2008 at 2:15 PM, Michael Schuh <[EMAIL PROTECTED]>wrote: > >> Hallo @list, >> >> Let us say i have a Machine with 8 CPUs and a lot of RAM. >> An i need a very high perfomance Storage for holding data. >> >> My idea was to setup a raid1(0) with virtual disk images. >> Created with mdconfig. >> >> My idea was to create minimum 2 md-diskimages, >> these are located >> fisrt one on the harddisk as type vnode >> second one as exact copy totally in the memory as type malloc >> >> For now the man-page mentoid me to not to do so, while large disks in RAM >> cause panics, and i know panics come surely >> >> Is the above scenario possible without panics? >> > > My first concern is not the panics (you can somewhat solve this by using > swap-backed MD), but the fact that you can't really gain an advantage this > way. > > If you have enough RAM, the regular process of filesystem buffering will do > the work for you. If you don't have enough RAM, the RAM starvation of > buffers and processes will be your problem and not the speed of your > filesystem. > > Regardless, if you were to construct a raid with an MD and a real disk (no > need to make it a vnode MD --- but that has the same drawbacks) the RAID > filesystem would be constrained by the speed of writes to the slower > filesystem. You may get a few percent out of teaching the gmirror node to > prefer reading from the memory disk, but would this be an advantage over the > natural buffering that already takes place? Probably not. > > -- === m i c h a e l - s c h u h . n e t === Michael Schuh Postfach 10 21 52 66021 Saarbrücken phone: 0681/8319664 mobil: 0177/9738644 @: m i c h a e l . s c h u h @ g m a i l . c o m === Ust-ID: DE251072318 === ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bad NFS/UDP performance
> it more difficult than I expected. > for one, the kernel date was missleading, the actual source update is the > key, so > the window of changes is now 28/July to 19/August. I have the diffs, but > nothing > yet seems relevant. > > on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' > and the 'bad' > give the same throughput, which seem to point to UDP changes ... Can you post the network-numbers? -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Spam ? - Re: Increasing partition size by removing partitions
I dont know if it going to be of any use, but in the past, I have used a free but very low level partition editing tool called Ranish http://www.ranish.com/part/ It does allow for moving of any partitions (or slices in BSD terms) Watch out though, as there is no real checks done against commands you issue (It WILL do exactly what you ask - be it right or wrong) I have used it (v2.44 - the lastest beta version) in the past for moving, growing and shrinking of NTFS and FAT32 partitions with a FreeBSD slice on the drive, just never tried changing a BSD slice it self If I remember right, if you try to run the editor under windows 2000 or XP, it will try to create a bootable floppy disk which might be more useful to FreeBSD users Like I said, it might not be any use in this instance, but probably still worth a look, just incase Paul On Sunday 28 September 2008 02:38:14 Maxim Khitrov wrote: > On Sat, Sep 27, 2008 at 7:22 PM, Aryeh M. Friedman > > <[EMAIL PROTECTED]> wrote: > > I have a disk that is laid out with partion 0 being NTFS and 1 being > > FreeBSD. I want to remove the NTFS partition and grow the FreeBSD one > > but all the docs I have seen only talk about how to do this if the new > > part of the partition is at the end of the partition you wish to grow. > > How do I go about this? > > Assuming that there is no (free) software that will do it for you, and > you are unable for some reason to move the data to another place and > repartition the drive, you have to manually move your FreeBSD > partition back and then extend it. I've never done this before, but if > I had to try it the first time I would do the following: > > 1. Try very hard to find some other hard drive where I can just dump > the data and avoid this whole thing to begin with. :) > 2. Boot from a FreeBSD livecd, attach a usb drive for storing some > temporary files and mount it under /mnt. > 3. Create a back-up of your master boot record (dd if=/dev/ad0 > of=/mnt/mbr-backup bs=512 count=1). Assuming here that your drive is > ad0. > 4. Use fdisk to get the start and size values of your two partitions > (in sectors). > 5. Erase the ntfs partition (dd if=/dev/zero of=/dev/ad0s1 bs=2m). > 6. Copy your FreeBSD partition to the former start location of ntfs > (dd if=/dev/ad0 of=/dev/ad0 bs=512 iseek= > oseek= count=). Using > bs=512 is slow, but it makes it easier for you to just take the > numbers that fdisk gives you and plug them in. > 7. Once this is done you will need to edit your mbr sector to > overwrite the first partition entry with the second, but certain > fields will need to be updated... > > I recommend you use a hex editor and work on the file that you saved > in step 3. You can try the same thing with a partition editor, but you > may not get the desired results. > > For the manual (and more fun) method, the partition table begins at > offset 0x01BE, and each entry is 16 bytes long. That means that you > need to copy 16 bytes starting at address 0x01CE to address 0x01BE. > However, before you do this, you need to set the correct values for > cylinder-head-sector of first and last sectors in the FreeBSD > partition, as well as the logical address of the first sector. > > First, take 3 bytes starting at address 0x01BF and copy them to > 0x01CF. This takes care of CHS start, which is unchanged. Next, take 4 > bytes at address 0x01C6 and copy them to 0x01D6. This is the logical > sector start. The tricky bit is the CHS last sector value. If your two > partitions were of identical size, then you can copy 3 bytes from > 0x01C3 to 0x01D3. Otherwise, you'll need to calculate the new values > by hand. If your NTFS partition was marked as active before, then set > byte 0x01CE to be 0x80. > > One this is done, copy that second record over the first and zero-out > the 16 bytes at 0x01CE. Use dd again to copy the updated mbr sector to > your drive. At this point your master boot record will have the > correct entry for your FreeBSD partition, which was moved over the > NTFS one. See if you can mount /dev/ad0s1a while still in the livecd > environment (actually, you will need to reboot first). If ad0s1a is > under /dev and you can mount it, then your mbr is fine. Use growfs > from here and then boot from the hard drive. > > As you can see, it's not a trivial thing to do, but it's possible if > you are careful. Once again, I've never done this and am basing the > whole thing on some of my previous experience in messing with the > master boot record. There may be some other things that I missed. I > also don't know if there is existing software that might make this > whole process much easier, the directions here are a worst-case > scenario for moving your partition by hand. > > - Max > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" __
Re: atacontrol broken in 7.1-PR
In message <[EMAIL PROTECTED]>, "Andrey V. Elsukov" writes: >This is known problem and it fixed in CURRENT. >You need to apply this patch: >http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/atacontrol/atacontrol.c.diff?r1=1.47;r2=1.48 > >I cc'ed person, who commited this fix. >Hi, Poul-Henning, I think it should be MFCed before release. I agree, but I'm ENOTIME. -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bad NFS/UDP performance
> > it more difficult than I expected. > > for one, the kernel date was missleading, the actual source update is the > > key, so > > the window of changes is now 28/July to 19/August. I have the diffs, but > > nothing > > yet seems relevant. > > > > on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' > > and the 'bad' > > give the same throughput, which seem to point to UDP changes ... > > Can you post the network-numbers? [again :-] > > Writing 16 MB file > > BSCount / 7.0 --/ / 7.1 -/ should now read: / Aug 18 --/ /--- Aug 19 / > >1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s > >2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s > >4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s > >8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s > > 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s > > 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s > > 64*512512 0.22s 71.45MB/s 0.45s 35.41MB/s > > 128*512256 0.21s 77.84MB/s 0.51s 31.34MB/s > > 256*512128 0.19s 82.47MB/s 0.43s 37.22MB/s > > 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s > > 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s > > 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s > > 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s > > 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s > >16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s > >32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s > > > > Average: 75.8633.00 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bad NFS/UDP performance
> > On Fri, 26 Sep 2008, Danny Braniss wrote: > > > > > after more testing, it seems it's related to changes made between Aug 4 > > > and > > > Aug 29 ie, a kernel built on Aug 4 works fine, Aug 29 is slow. I'l now > > > try > > > and close the gap. > > > > I think this is the best way forward -- skimming August changes, there are > > a > > number of candidate commits, including retuning of UDP hashes by mav, my > > rwlock changes, changes to mbuf chain handling, etc. > > it more difficult than I expected. > for one, the kernel date was missleading, the actual source update is the > key, so > the window of changes is now 28/July to 19/August. I have the diffs, but > nothing > yet seems relevant. > > on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' > and the 'bad' > give the same throughput, which seem to point to UDP changes ... > > danny Grr, there goes binary search theory out of the window, So far I have managed to pinpoint the day that the changes affect the throughput: 18/08/08 00:00:00 19/08/08 00:00:00 (I assume cvs's date is GMT). now would be a good time for some help, specially how to undo changes, my knowledge of csup/cvs are close to zero. danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What file on FreeBSD acts like autoexec.bat?
Mike Price <[EMAIL PROTECTED]> wrote: > What file on FreeBSD acts like autoexec.bat? > Also please leave the full path% The file that probably comes closest is /etc/rc.local (you have to create it, it doesn't exist by default). Actually FreeBSD's rc system allows much more flexible scripting ... If you're interested, start by reading the rc(8) manual page. But if you only need some simple commands executed upon every boot, just put them in /etc/rc.local and you're done. Note, however, that you have to use sh(1) shell command syntax, not COMMAND.COM syntax. ;-) By the way, the file that corresponds to config.sys on a FreeBSD system is /etc/rc.conf (see the rc.conf(5) manual page for details). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "A language that doesn't have everything is actually easier to program in than some that do." -- Dennis M. Ritchie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
