Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage?
On Tue, 8 Oct 2013 16:01:25 -0700 Davide Italiano wrote: This could be probably changed -- from what | see even under high memory pressure this wasn't a problem but all in all I agree with you that we shouldn't loop forever but limit the number of pass on the list to a somewhat constant number, to prevent pathological cases. I don't see any need to loop. I don't believe that's true. Under most circustances the existing scheme free more memory. The only case when yours frees more is when 90% of the entries are locked. Well, no. Here you can set the threshold to a more aggressive value so that you reclaim more memory every time. Note that this was not possible in the previous version, so, if you could have a situation where all your cache entries were not touched for 15 or even 30 seconds they would have kept around, and you can destroy up to 10% of them everytime lowmem event is called. Outside of contrived stress tests I think it's very rare for a significant fraction of the cache to have been accessed in the last minute - particularly on large caches where this matters most. ___ 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: mmap() question
On Wed, 9 Oct 2013 15:42:27 +0400 Dmitry Sivachenko wrote: Hello! I have a program which mmap()s a lot of large files (total size more that RAM and I have no swap), but it needs only small parts of that files at a time. My understanding is that when using mmap when I access some memory region OS reads the relevant portion of that file from disk and caches the result in memory. If there is no free memory, OS will purge previously read part of mmap'ed file to free memory for the new chunk. ... It seems I incorrectly understand how mmap() works, can you please clarify what's going wrong? I expect that program to run indefinitely, purging some regions out of RAM and reading the relevant parts of files. I think your problem is that you are accessing the memory so rapidly that the pages can't even get out of the active queue. The VM system isn't optimized for this kind of abnormal access. ___ 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 Tue, 8 Oct 2013 13:32:58 +0200 Davide Italiano wrote: On Tue, Oct 8, 2013 at 1:25 PM, Adrian Chadd adr...@freebsd.org wrote: Hi, Hi Adrian, Please try it out on a -10 VM with something RAM limited - say, 128mb w/ GENERIC. See how it behaves. Be aware that any test that doesn't cause vfs.ufs.dirhash_lowmemcount to increment isn't testing the change at all. This is not supposed to hit 10-STABLE, at least not before proper review. This is the reason why it was proposed on mailing lists. Also, if you read the patch you'll end up with realizing this should behave better on low memory environment because it unconditionally cleans 10% of the cache every time. The current version deletes anything older than the time limit and if this doesn't reclaim 10% it makes a second pass through the list until the target is met. Your version tries to delete 10% (or whatever) by looping around the list until this is achieved. And if there aren't enough unlocked entries it will loop indefinitely until there are. I hope you know what you are doing because that looks very wrong. The original version looks better to me given that it already tries to free a minimum of 10%. The low-memory handler is called under very low memory conditions when the system is probably thrashing or even on the verge of killing processes. Holding on to entries that haven't been used for a minute seems like a luxury. Previous changes in this area just did the opposite keeping a lot more of memory around. I don't believe that's true. Under most circustances the existing scheme free more memory. The only case when yours frees more is when 90% of the entries are locked. ___ 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: weekly periodic security status
On Sun, 25 Aug 2013 22:03:58 +0200 Jeremie Le Hen wrote: I've implemented it here: http://people.freebsd.org/~jlh/security_status_period.diff Doesn't this mean that if you want to run periodic security from crontab or manually etc, you have to override every single entry to crontab in period.conf. IMO when periodic security is run directly every test should run unless it's explicitly set to NO. ___ 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: weekly periodic security status
On Thu, 22 Aug 2013 22:49:58 +0200 Jeremie Le Hen wrote: Hi, I plan to commit the attached patch. This allows the turn the daily security checks into weekly checks. You do this by adding the following to periodic.conf(5): daily_status_security_enable=NO weekly_status_security_enable=YES All other $daily_status_security_whatever variables will be renamed to $security_status_whatever. The old variable name is supported but prints a warning. All daily_status_security_enable does is control whether the security scripts are run from daily, but security is a periodic dirctory in its own right. You can simply set daily_status_security_enable=NO and put a separate security entry in crontab (or anacrontab). You can also symlink the lightweight security scripts in a separate directory and run those on all, or some, of the days you don't run the full security pass. In short the current support is more powerful and flexible than anything suggested in this thread so far. ___ 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: seeding randomness in zee cloud
On Fri, 31 May 2013 12:01:02 +0200 Dirk-Willem van Gulik wrote: Now we happen to have very easy access to blocks of 1024bits of randomness from a remote server in already nicely PKI signed packages (as it is needed later for something else). Is it safe to simply *add* those with: set -1 # fetch randomness check signature .. snipped... # Seed Software random generator # cat rnd /dev/random To be on the safe side you should sleep for about 0.5 seconds after this # Activate software random generator as an additional source sysctl kern.random.sys.harvest.swi=1 IIRC this doesn't do anything ___ 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: seeding randomness in zee cloud
On Fri, 31 May 2013 14:26:39 +0200 Dirk-Willem van Gulik wrote: Op 31 mei 2013, om 14:02 heeft RW rwmailli...@googlemail.com het # Activate software random generator as an additional source sysctl kern.random.sys.harvest.swi=1 IIRC this doesn't do anything Thanks. So the man page says: The kern.random.sys.harvest.swi variable is used to select software interrupts as an entropy source. A 0 (zero) value means software inter- rupts are not considered as an entropy source. Set the variable to 1 (one) if you wish to use them for entropy harvesting. I don't think it ever got implemented, but for some reason the sysctl got left in. All it would have done is turn-on an additional entropy source. but it is fair to assume that even when it is set to '0' (the default observerd on 9.1-RELEASE) - that the randomness sent to /dev/random is still mixed in ? Yes, if you are using the software generator then it's used. If you have direct hardware support you wont see the harvest sysctls and the input is harmlessly discarded. Most Ivy Bridge and newer AMD processors have RdRand these days. ___ 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: MADV_FREE and wait4 EFAULT
On Tue, 16 Apr 2013 14:12:54 -0700 Carl Shapiro wrote: I am seeing wait4 system calls failing with an EFAULT and I am trying to understand what might be going wrong. An inspection of the wait4 implementation suggests the opportunity for EFAULT is within its invocations of copyout. In my situation, the status and rusage pointer arguments contain addresses to mmaped pages which have been madvised as MADV_FREE. Is it permissible to pass pages which have been madvised MADV_FREE to wait4 or any other system call for that matter? Might there be another opportunity for a wait4 to EFAULT? IIRC MADV_FREE pages are marked clean and placed on the end of the inactive queue as low hanging fruit for the page daemon. AFAIK they're no different to any other clean page. Malloc'ed memory pages are commonly in that state. ___ 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: cvs deprecated
On Sun, 30 Dec 2012 13:18:37 + Chris Rees wrote: On 30 Dec 2012 12:58, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: do ports have to be updated this way or i can use portsnap as today? will portsnap be continued or is too deprecated? Portsnap is staying. And I understand that freebsd-update can be configured to only update the base system source code. If you don't want development branches you can do without subversion altogether. ___ 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: cvs deprecated
On Thu, 27 Dec 2012 02:33:00 -0800 Garrett Cooper wrote: On Thu, Dec 27, 2012 at 2:30 AM, Chris Rees utis...@gmail.com wrote: I recall a cluster administrator advising use of svn protocol rather than http. Something to do with overheads. Yes, you're right. http opens a connection per-file, which is horrendous with server load and is very slow as HTTP isn't optimized for this purpose Presumably that's a limitation of the library or subversion because it's not true of HTTP per se. Portsnap, for example, uses persistent connections with pipelining. (and the current defacto HTTP library used with svn isn't the most performant thing in the world). ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, 19 Jun 2012 01:04:47 -0400 Richard Yao wrote: On 06/19/2012 12:39 AM, Wojciech Puchar wrote: - delay at rc.d scripts - there are some delays inserted. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. grep sleep /etc/rc.d/* usr/local/etc/rc.d/* So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost it is unimportant as FreeBSD don't crash. OpenRC init scripts lack such delays. They store dependency information, which enables OpenRC to start them as soon as their dependencies are ready. That's not the reason for the sleeps. FreeBSD sorts the scripts into dependency order and runs them sequentially, so there's no reason to sleep waiting for a dependency script to complete. The sleeps exist for a variety of reasons. Just looking at the grep can be a bit misleading. Not all of the scripts are going to be used, the sleep is not always relevant to startup, in some case it's in a code path that's not typically taken. One thing that I think could be easily improved is that the polling delays could be changed from 1 second to 0.1 seconds. If there's a reason for rc scipts needing to be portable, there could be a polling delay function with a fast polling option in defaults/rc.conf. ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, 19 Jun 2012 11:03:31 -0700 Garrett Cooper wrote: On Tue, Jun 19, 2012 at 10:51 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: grep sleep /etc/rc.d/* usr/local/etc/rc.d/* Sleeps in /etc tend to be there for good reasons, and new ones are vigorously scrutinized. If you see any that you think are dubious, feel free to mention them on freebsd-rc@. I don't say they are not needed but that they exist. anyway i don't understand sleep 1 after setting default route. Probably working around annoying races in the driver / network / routing stack. Please see my previous reply. There are a few sleeps where some action is performed and and then a fixed sleep is done, but this is one of the ones where the sleep is in a while loop - a full second seems a bit long. ___ 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: BUG: REL 9.0 - MD malloc of custom sector size
On Sun, 18 Mar 2012 14:01:39 +0100 rank1see...@gmail.com wrote: man mdconfig -S sectorsize to use for malloc backed device I want to create MD device, with sector size of 4 Kb. It is CRITICAL to NOT append ANY suffixes, when specifing size, via '-s' flag in order to use sectors, to set it's size. # mdconfig -a -t malloc -S 4096 -s 32768 This should created dev of 128 Mb in size. 32768 sectors * 4 Kb each = 131072 Kb = 128 Mb Not! It created dev of 16 Mb in size, because sector size remained at 512 bytes. From mdconfig 8 Size is the number of 512 byte sectors unless ... Looks to me like it's doing what it said it would. BTW are you sure you want to use -t malloc. This keeps the files (even the deleted ones) in memory unconditionally while ordinary process memory is paged-out. ___ 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: Graphical Terminal Environment
On Tue, 6 Mar 2012 10:31:49 +0100 Björn Oelke wrote: Am 06.03.2012 um 06:48 schrieb Brandon Falk: I havent tried tmux yet, but on my system im only able to get 80x40 with vidcontrol on one monitor. But with xterm in xorg i can get 319x89 per monitor. Until i get about half of that, i wont be convinced to use something existing. Anyways, I'm off to sleep. Have you tried VESA's SC_PIXEL_MODE? It's a kernel option and IIRC it works on amd64 since 8.1. `vidcontrol MODE_282` gave me 1280x1024 pixels. But to be honest, this was about two years ago. Since I did this recently, you need to build with options VESA options SC_PIXEL_MODE Then run vidcontrol -i mode to get a list of modes. Choose one and then run vidcontrol with something like: -g 160x64 MODE_283 where 160x64 comes from dividing the mode's font size into its resolution. You can make that automatic by adding allscreens_flags=-h 2000 -g 160x64 MODE_283 to rc.conf BTW does anyone know what the character at the end of the size field is in the vidcontrol -i mode output, I'm seeing D,P or 4 on the graphics modes. ___ 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: Invalid memory stats from vmstat and sysctl vm.vmtotal?
On Wed, 30 Nov 2011 12:39:10 - Steven Hartland wrote: We're seeing some impossible memory usage stats reported on machines here from vmstat and sysctl vm.vmtotal. We have machines reporting to be using 31GB total when they only have 8GB physical and are not using any swap. Here's an output from one of our machines:- vmstat -c 2 -w 1 -n 0 procs memory page faults cpu r b w avmfre flt re pi pofr sr in sy cs us sy id 0 0 0 31768M 2112M 586 0 0 0 421 0 106 270 569 0 6 94 0 0 0 31768M 2112M 2 0 0 0 0 0 370 8139 3996 0 1 99 ... It looks like it may be out by a factor of 4, possibly due to the fact the its a 4k page size not 1k as indicated by the vmstat man page:- I don't think so, I have 16GB and tops shows: Mem: 817M Active, 396M Inact, 1364M Wired, 82M Cache, 1282M Buf, 13G Free but vmstat -c 2 -w 1 -n 0 procs memory page faults cpu r b w avmfre flt re pi pofr sr in sy cs us sy id 0 0 0 9750M13G 450 5 3 1 560 0 234 50201 5206 2 2 96 1 0 0 9742M13G79 4 0 0 573 0 239 51886 4700 0 1 99 ___ 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: Recommended amount of swap
On Mon, 5 Sep 2011 14:48:57 -0500 Dan Nelson wrote: In the last episode (Sep 05), Sean Hamilton said: What is the state of the art for the recommended amount of swap in FreeBSD? Both normal systems with 512 MB - 8 GB of RAM, and large database systems with around 128 - 256 GB. I suggest 2x RAM for systems less than 4gb or so. Anything more than 4GB of swap is probably never going to be used, and if it is used, you're just going to thrash your swap device. but tmpfs (and swap-backed md devices) can use substantial amounts of swap without contributing to thrashing. In some cases it may be possible to justify larger amounts of swap. ___ 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: Phenom II 975 BE shows 0 celsius
On Mon, 1 Aug 2011 19:21:38 -0300 Mario Lobo wrote: On Monday 01 August 2011 15:52:30 Matthew D. Fuller wrote: On Sun, Jul 31, 2011 at 09:28:29PM -0300 I heard the voice of Mario Lobo, and lo! it spake thus: Unfortunately this Mobo died and only found AM3 boards for which my phenom 955 doesn't fit. Not that it helps you now, but the 955 _is_ perfectly compatible with AM3. It's only the initial 920 and 940 that were AM2-only. I was just following this: http://support.amd.com/us/kbarticles/Pages/CPU-6-socket-am2-plus-phenom-ii- compatibility-alert.aspx It says Although Socket AM3 processors can be used on Socket AM2+ motherboards, the opposite is not possible. I'm using a 955 in a M4A88T-M/USB3, which is minor variant of your AM3 board. My understanding is that the 955 is an AM3 processor. BTW in my case only the temperature is correct, but is only given for the first 2 cores. ___ 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: Why FreeBSD fetch does not download a file via a proxy for HTTPS URLS (the same works fine for HTTP urls)
On Thu, 24 Feb 2011 12:49:06 +0530
chandra reddy cred...@gmail.com wrote:
Hi All,
I am working on a project where i need to download a file via a proxy
server using HTTPS protocol. I found that fetch does not work/support
HTTPS requests over a proxy.
I just checked and neither do wget nor curl.
I could overcome the above problem if I do the following change.
1375:
1.58
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libfetch/http.c#rev1.58
des 1376:if (purl) { 1.51
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libfetch/http.c#rev1.51
des 1377:URL = purl;
I don't think that would work, presumably it would just cause an
attempt at an ssl connection to the proxy, followed by a GET request
for an https URL. https through a proxy is supposed to use a CONNECT to
tunnel through to the actual server.
___
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: IPSEC allegations
On Wed, 15 Dec 2010 06:56:58 -0800 (PST) Jakub Lach jakub_l...@mailplus.pl wrote: Hello. http://marc.info/?l=openbsd-techm=129236621626462w=2 What's your insight? There's already a thread on this on the security list. ___ 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
MADV_FREE and vm_page_dontneed()
Is there a good reason why physical memory pages released by madvise(...,MADV_FREE) get handled by vm_page_dontneed()? vm_page_dontneed() leaves page that are already in the inactive queue where they are, and otherwise distributes pages between the active queue, and the inactive queue's tail and head in the ratio 1:3:28. That seems reasonable for MADV_DONTNEED, but MADV_FREE pages are from freed dynamic memory, so passing them to vm_page_dontneed() leads to wasted pages building-up in the active and inactive queues. Wouldn't it make more sense to move all eligible MADV_FREE pages to the head of the inactive queue? ___ 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: Summary: Re: Spin down HDD after disk sync or before power off
On Thu, 21 Oct 2010 12:21:10 + Alexander Best arun...@freebsd.org wrote: atacontrol(8) says that: You should not set a spindown timeout on a disk with / or syslog logging on it as the disk will be worn out spinning down and up all the time. this seems to indicate that spinning down a disk has quite an impact. That's mostly likely a hang-over from older disk technologies when the heads touched the surface on spinning down. ___ 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: Summary: Re: Spin down HDD after disk sync or before power off
On Thu, 16 Sep 2010 09:17:52 +0200 Dag-Erling Smørgrav d...@des.no wrote: Garrett Cooper gcoo...@freebsd.org writes: Agreed. Spinning down at reboot isn't smart and seems like a good way to kill a disk quicker. *not* spinning down at halt is far worse. Most modern disks are rated for hundreds of thousands of load-unload cycles, but far fewer emergency unloads (which is what happens when the drive loses power while still spinning). As I understand it wear from spinning-down used to come from the head actually scraping the disk surface as it lost lift, parking placed the head on a disposable area, but modern drives take the head off the disk altogether. When Hitachi was specifying 300,000 unloads, they said that in testing the drives were still working at 1,000,000, someone quoted 600,000 as the current spec. At these levels you can be spinning the drives down and up ever few minutes for the normal lifetime of the drive. Even on very old drives I doubt reboot are much of a problem, they're rare on servers. On laptops and desktops they're rare compared to shutdowns and suspends. ___ 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: pageout question
On Sun, 25 Jul 2010 23:43:08 +0300 Andriy Gapon a...@freebsd.org wrote: on 25/07/2010 23:28 RW said the following: I didn't say it say it was guaranteed. I just think the scenario where a first pass ends up between the watermarks is rare. And when it happens I don't see a compelling reason to do extra paging to reach an arbitrary target. Well, it seems neither I nor you have data to show whether it's rare or not (and it would greatly depend on workload too). As to arbitrary target - well, that's the whole point of hysteresis-like behavior. We start paging also at an arbitrary point. If after the first pass with light-paging the high watermark isn't reached then the choices are 1) loop and immediately do a heavy-paging pass. 2) wait and let the daemon get woken-up for another light-paging pass - only go to heavy-paging when this strategy isn't keeping up with demand. To me (2) is doing the right thing. It's trying to satisfy demand from existing clean pages, and only paging heavily as a last resort. ___ 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: pageout question
On Sun, 25 Jul 2010 13:07:21 +0300 Andriy Gapon a...@freebsd.org wrote: on 25/07/2010 02:31 RW said the following: As I understand it the hysteresis is done inside vm_pageout_scan, and the expectation is that one pass will typically satisfy this because the design aims to keep enough clean pages in the inactive queue. But I am not sure about clean pages in the inactive queue ... But I do not see any code ensuring level of _clean_ inactive pages. In FreeBSD the inactive queue contains disk cache pages which normally provide most of the clean pages needed. In addition pages are dribbled out to swap, and the resulting clean pages are placed at the back of the inactive queue to make another pass. I'm not sure if the vm_paging_needed() call is correct or not, but it may be that that the intent is to avoid immediately going back to a depleted inactive queue when cache+free is within normal bounds, because it could result in avoidable paging to swap. Well, OTOH, if the current pass results in many pages being re-activated and many pages still left on the inactive queue because they are dirty (see maxlaunder in vm_pageout_scan), Dirty-pages make three passes through the inactive queue: twice dirty, once clean. They are paged-out at the end of the second paass, so it's unlike that they reactivated except under very heavy thrashing. then it is premature to quit paging when we only reached bare minimum of available pages (see pass and maxlaunder again). IMHO, of course. It's not the bare minimum, that's another level that vm_page_count_min() tests for. ___ 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: pageout question
On Sun, 25 Jul 2010 17:19:41 +0300 Andriy Gapon a...@freebsd.org wrote: on 25/07/2010 16:41 RW said the following: In FreeBSD the inactive queue contains disk cache pages which normally provide most of the clean pages needed. In addition pages are dribbled out to swap, and the resulting clean pages are placed at the back of the inactive queue to make another pass. Well, normally and most are not quite quantitative. Personally, I do not see any guarantees that inactive queue would contain enough clean pages to reach paging target on a single pass. I didn't say it say it was guaranteed. I just think the scenario where a first pass ends up between the watermarks is rare. And when it happens I don't see a compelling reason to do extra paging to reach an arbitrary target. I think the comment about not clearing vm_pages_needed is referring to clearing it below the low-watermark because the daemon would then get woken-up almost immediately. I meant bare minimum to stop paging, that is, going above lower watermark of the paging hysteresis. ___ 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: pageout question
On Sat, 24 Jul 2010 23:23:07 +0300
Andriy Gapon a...@freebsd.org wrote:
There is a good deal of comments in the vm_pageout.c code that imply
that we use a hysteresis approach to deal with low available pages
condition.
In general, the hysteresis, the comments and the code make sense.
My doubt, though, is about the block of code that is right below the
comment quoted above:
if (vm_pages_needed !vm_page_count_min()) {
if (!vm_paging_needed())
vm_pages_needed = 0;
wakeup(cnt.v_free_count);
}
As I understand it the hysteresis is done inside vm_pageout_scan, and
the expectation is that one pass will typically satisfy this because the
design aims to keep enough clean pages in the inactive queue.
I'm not sure if the vm_paging_needed() call is correct or not, but it
may be that that the intent is to avoid immediately going back to a
depleted inactive queue when cache+free is within normal bounds,
because it could result in avoidable paging to swap.
___
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: thoughts on sorting files into sub-folders by access date?
On Thu, 1 Jul 2010 10:20:25 -0700
Steve Franks bahamasfra...@gmail.com wrote:
Hi y'all,
My high-end pointshoot camera likes to glob all my photos in a single
folder, and it's glutting up my drive, and makes finding a specific
trip unpleasant, with no good place for metadata. My SLR sorts them
into folders by date, which I love.
...
I thought I'd check if there's some trivially simple way of doing this
with bash find first.
If the timestamps are acccurate you could simply loop around the files
and do something like this (untested):
dir=${targetdir}/`stat -f %Sm -t %Y%m%d ${file}`/
[ -d ${dir}] || mkdir ${dir}
mv ${file} ${dir}]
___
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: thoughts on sorting files into sub-folders by access date?
On Thu, 1 Jul 2010 22:08:55 +0100
RW rwmailli...@googlemail.com wrote:
dir=${targetdir}/`stat -f %Sm -t %Y%m%d ${file}`/
[ -d ${dir}] || mkdir ${dir}
mv ${file} ${dir}]
Should be:
dir=${targetdir}/`stat -f %Sm -t %Y%m%d ${file}`/
[ -d ${dir} ] || mkdir ${dir}
mv ${file} ${dir}
___
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: Aurora Scheduler
On Sat, 05 Jun 2010 20:16:49 -0400 jhell jh...@dataix.net wrote: I'm afraid that you are confused about what the scheduler in the FreeBSD kernel does and what the Aurora Scheduler is. They are not relational to one another in any such way. ... There is not a similiar scheduling program in FreeBSD but there is Evolution, Kontact and other such things to manage your time. I suspect he's talking about using algorithms from project management software in an embedded kernel to help it schedule around real-time deadlines and so on. ___ 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: Common OS/kernel code between freebsd and linux
On Sat, 22 May 2010 05:09:31 -0700 Anjali Kulkarni anj...@juniper.net wrote: I am not sure the right forum to ask this question - is there any effort done to find portable code between different OSes, particularly freebsd and linux? BSD code has been used in most operating systems due to its open licence, but it's very awkward to mix GNU/Linux GPLed code with BSD code without the whole thing ending up GPLed. ___ 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: regenerating /var/db/pkg
On Thu, 22 Apr 2010 20:05:48 +0300 Eitan Adler eitanadlerl...@gmail.com wrote: bak=/var/backups This should be configurable IMO. ___ 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: yarrow random generator
On Fri, 25 Dec 2009 13:38:10 -0800 Doug Barton do...@freebsd.org wrote: Robert Watson wrote: I'll point Mark Murray at this thread and see if we can get him to opine some on the current design choices and any potential changes to address them. I was interested by your observation that the boot-time dumping of bits into /dev/random may overflow the buffering -- I was peripherally involved in the introduction of yarrow in the sense that I wrote most of the rc and periodic stuff for it so I am also interested in this issue. Rather than speculating about whether it's overflowing the buffer perhaps a patch can be produced to test this hypothesis? It's not really speculation, the data is broken into 16 byte chunks, random_harvest_internal() is called to copy each chunk into a buffer and queue it. If there are 256 or more buffers in the queue random_harvest_internal() returns without doing anything. The kernel thread that processes the queues calls pause(-, hz /10) each time it loops. A fairly simple solution would be piping all that low-grade entropy from sysctl and ps etc through sha256, reducing it to 64 bytes. ___ 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: yarrow random generator
On Thu, 24 Dec 2009 19:48:43 + (GMT) Robert Watson rwat...@freebsd.org wrote: On Thu, 24 Dec 2009, Paul Graphov wrote: And also according to Schneier it is a good idea to save state of the PRNG and restore it on boot to make it more seeded. In the default configuration, we save some PRNG output every few minutes (using cron) to a file in /var so that it can be re-injected into Yarrow on the next boot (done by /etc/rc.d/random). It isn't handled very well though. The files saved by crontab under /var are loaded a bit late in the boot sequence - after encrypted swap. The main entropy file is loaded earlier, but immediatly after ps -fauxww, sysctl -a, etc are dumped into the device, saturating its 4K of buffer space. ___ 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: (Ab)using rcng's features to keep rc.d-style services running should they fail.
On Sun, 4 Oct 2009 15:11:18 +0100 Alex Trull a...@trull.org wrote: Hi all, I realised that because portupgrade/portmaster don't always cleanly restart processes that have died due to being upgraded (mysqld, often!) that this was something I wanted to fix. You can configure portupgrade (and FWIW portmanager) to do this. Take look at the sample configuration file. ___ 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: the web site
On Sun, 29 Mar 2009 17:40:30 -0400 Chuck Robey chu...@telenix.org wrote: I just had to see if I could locate if there was a gnome project page by looking at the FreeBSD web pages. Why don't you try that yourself? I'll tell you, it's really FAR from being obvious. I'm just saying, even if folks don't want to change the web page, then a TOC-like section should be added near the bottom, to make navigation easier. If you click on site map, at the bottom of the page, the gnome link is on the first line. ___ 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: Remote kernel debugging in FreeBSD using serial communication
On Sat, 17 Jan 2009 17:57:10 -0800 (PST) Kamlesh Patel shilp.ka...@yahoo.com wrote: Hi All, I am trying remote kernel debugging in FreeBSD using serial communication. I got the following link. http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1 My problem is my developing and target system does not have DS25 female port. Anyone have any idea about Remote kernel debugging in FreeBSD using DS9 F/F Serial cable or any other remote debugging idea? Have you tried following the link about 9-pin null-modem cables on the above page? Is there a particular problem? If you go to PC World, or equivalent, a null modem cable will have 9-pin connectors. ___ 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: 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
On Fri, 26 Sep 2008 20:15:43 +0200 Michael Schuh [EMAIL PROTECTED] wrote: 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? You could use swap-backed devices. They are very similar, in both cases you are writing into ram backed by swap. I doubt it will work, I think raid works at the speed of the slower device. You need to be careful how you benchmark it. Your raid array will have the unfair advantage of starting with preloaded data. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What is difference between /etc/rc called programs and ones called after login prompt shows up
On Sat, 23 Aug 2008 15:33:54 +0200 Gary Jennejohn [EMAIL PROTECTED] wrote: On Sat, 23 Aug 2008 06:34:23 -0400 Aryeh Friedman [EMAIL PROTECTED] wrote: What is difference between /etc/rc.d called programs and ones called after login prompt shows up? The reason for asking is sysutils/fusefs-kmod gives an error if any mounts are attempted in /etc/rc but if the exactly the same command is issued by a user's .login/.xsession/etc. it works without problem (assuming proper permissions of course). a) Can anyone think of a reason why this would happen (the maintainer is non-responive) Well, there are ways to force dependencies in the rc.d scripts, but I don't know the setup well enough to be helpful. I have no idea which script handles modules installed by ports and when it is invoked. You could try moving fuse.ko to /boot/modules and modify loader.conf to load fuse.ko at boot time. There's no need for that, it's already handled by the rc.d scripts. Fuse-based filesystems should be mounted with the late option, so they get mounted after the kernel module is loaded. You might also need a patch so the mount can find the correct mount_* executable.I think it's needed in 7.0, I'm not sure about 7-stable and current. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What is difference between /etc/rc called programs and ones called after login prompt shows up
On Sat, 23 Aug 2008 16:38:13 -0400 Aryeh Friedman [EMAIL PROTECTED] wrote: c) See a additionally to prove all the above here is my /etc/rc (the last 2 lines where added just to prove the point): #!/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin swapon -a fsck -p ... fuse: failed to exec mount program: No such file or directory Thus it is clear that the *ONLY* difference between the /etc/rc calls and the post getty calls is when they are made. There's another difference: your /etc/rc script doesn't export PATH. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What is difference between /etc/rc called programs and ones called after login prompt shows up
On Sat, 23 Aug 2008 23:13:49 +0100 RW [EMAIL PROTECTED] wrote: On Sat, 23 Aug 2008 16:38:13 -0400 Aryeh Friedman [EMAIL PROTECTED] wrote: c) See a additionally to prove all the above here is my /etc/rc (the last 2 lines where added just to prove the point): #!/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin swapon -a fsck -p ... fuse: failed to exec mount program: No such file or directory Thus it is clear that the *ONLY* difference between the /etc/rc calls and the post getty calls is when they are made. There's another difference: your /etc/rc script doesn't export PATH. That does seem to be the answer. I was curious as to why it only fails on ntfs, so I had a look at the source. It seems that mount and fsck find mount_* and fsck_* through a hard-coded path of /rescue:/sbin:/usr/sbin, but mount_ntfs-3g then additionally has to find mount_fusefs through the environment path. Perhaps sysutils/fusefs-libs should be patched to make the whole thing more self-consistent. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What is difference between /etc/rc called programs and ones called after login prompt shows up
On Sat, 23 Aug 2008 22:02:14 -0400 Aryeh Friedman [EMAIL PROTECTED] wrote: Thanks that did it... but you're incorrect in saying it is only ntfs it is all fuse based fs's I had a the same error when doing a fuse-ssh mount to my machine at work I meant only ntfs out of all the other entries in your fstab. If PATH isn't exported then the question became: why are any of the mounts or fscks succeeding? Presumably all the fuse filesystems are mounted in the same way mount -t foo -- mount_foo -- mount_fusefs as opposed to mount -t foo -- mount_foo for native filesystems. Since it turns out that only the mount_foo -- mount_fusefs call needs a PATH variable, all fuse filesystems will fail if PATH isn't exported, but no native filesystem will be affected. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: forcefsck on booting stage
On Mon, 28 Jul 2008 15:10:11 +0200 Marc L__rner [EMAIL PROTECTED] wrote: On Monday 28 July 2008 15:00, Jeremy Chadwick wrote: On Mon, Jul 28, 2008 at 04:11:49PM +0400, sam wrote: Hello, How to make 'fsck -f' on booting stage of remote system? I believe by setting background_fsck=no in /etc/rc.conf? That's the only way I know of, besides booting single user and doing it manually. Doesn't this only disable background fsck support? By creating file /forcefsck you can force an fsck at next reboot, because some scripts test for existence. That's in linux AFAIK, but it would be fairly straightforward to modify /etc/rc.d/fsck to get that behaviour though. fsck -f is interactive, so you would want to add the -y option to prevent its hanging waiting for console input. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years / thanks for responding
On Wed, 2 Jul 2008 23:36:09 -0400 Sean Cavanaugh [EMAIL PROTECTED] wrote: This is the first time I ever actually downloaded all 3 CD's so i didn't know what I was getting into. I had always just used the first CD for the initial install, then ports for everything else. Next time I will use the dvd. Actually that would have been perfect as I got one of those unusual 550kB/s connections from ftp, lol. But I decided this time to get as many packages as quickly as possible, then run portupgrade on them to get the latest versions. I think it might be easier to use pkg_add -r to get up-to-date 7-stable packages ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Modifying the loaded kernel image
On Fri, 27 Jun 2008 00:37:40 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: Also, HTML Email is incredibly annoying. And you know what's even *more* annoying? HTML Email that is sent with a text/plain MIME type, indicating it's not HTML. There was also a problem with the base64 encoding, claws-mail couldn't display the message at all ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lack of Flash support is no longer acceptable. Bounty established...
On Wed, 25 Jun 2008 11:52:30 +0300 Stefan Lambrev [EMAIL PROTECTED] wrote: I tried this before and have a bad luck of not having working audio on flash, but today with new wine and FF3 it works. Btw there is a small nasty problem copy/paste from wine app to native apps does not work. Ideas how to workaround this? It's only the traditional X, select and middle-click, that doesn't work in my experience The windows-style explicit cut/copy/paste works for me with KDE in both directions. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Decent 3D acceleration in 64bit mode?
On Thu, 19 Jun 2008 17:36:44 -0400 Chuck Robey [EMAIL PROTECTED] wrote: Could I ask, does anyone here know the reason (even in general) that the Nvidia driver isn't working on the i386? I presume you mean on amd64, since it does work on i386. http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 cpu_reset_real: code/comment mismatch
On Mon, 12 May 2008 17:34:35 +0300 Andriy Gapon [EMAIL PROTECTED] wrote: This is not a real issue, just a code clarification. First a snippet from sys/i386/i386/vm_machdep.c, cpu_reset_real() /* * Attempt to force a reset via the Reset Control register at * I/O port 0xcf9. Bit 2 forces a system reset when it is * written as 1. Bit 1 selects the type of reset to attempt: * 0 selects a soft reset, and 1 selects a hard reset. We * try to do a soft reset first, and then a hard reset. */ outb(0xcf9, 0x2); outb(0xcf9, 0x6); I think that the comment is correct up to but not including the last sentence. Writing 0x2 sets bit 1 to 1 (thus selecting hard reset), and writing 0x6 sets both bits 2 and 1 to 1 (thus performing hard reset). So we always just do a hard reset, no trying of soft reset (would it even make sense to do the last line of the comment says). It looks to me as if the comment was added retrospectively by someone who got the two bits mixed-up when reading the source. If bits 1 and 2 were the other way around, it would be code for a soft-reset followed by a hard-reset. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Yarrow's Counter
On Mon, 21 Apr 2008 14:48:30 +0400 Eygene Ryabinkin [EMAIL PROTECTED] wrote: Good day. Sun, Apr 20, 2008 at 06:31:35PM +0100, RW wrote: this modification seems not to help anything, It possibly doesn't help with an attack against Yarrow itself, but it means that 512 bits of entropy, rather than 256 bits, can be read-out from /dev/random. The only source of entropy is the entropy pool. The key and the counter are both derived from this pool, so if you will concatenate two 256 bit values you will not gain more entropy. ... Am I missing something? If you encrypt the previous value of the counter, instead of zero, the counter will then depend on all the previous keys, and not just the current one. With the default settings any two keys more than one reseed apart are completely independent. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Yarrow's Counter
On Sat, 19 Apr 2008 23:30:23 +0400 Eygene Ryabinkin [EMAIL PROTECTED] wrote: I would not do it without consultations with Yarrow's creators: OK, I didn't realise it was actually specified, I thought it an implementation detail. this modification seems not to help anything, It possibly doesn't help with an attack against Yarrow itself, but it means that 512 bits of entropy, rather than 256 bits, can be read-out from /dev/random. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Yarrow's Counter
The random number generator in FreeBSD's Yarrow implementation uses AES256 in counter mode. When a reseed occurs the generator is reinitialised like this: - generate a new cypher-key from the pool[s] and the old key - zero the counter - encrypt the (zeroed) counter with the new key My question is: why zero the counter? If it's not zeroed then the old counter is encrypted instead, and after a few reseeds the counter will accumulate an independent 256 bits of entropy, rather than being a function of the new key. Should I submit a patch, it's simply a matter of deleting two lines in reseed() in sys/dev/random/yarrow.c. yarrow_hash_finish(context, temp); yarrow_encrypt_init(random_state.key, temp); /* 4. Recompute the counter */ for (i = 0; i 4; i++) --- random_state.counter[i] = 0; --- yarrow_encrypt(random_state.key, random_state.counter, temp); memcpy(random_state.counter, temp, sizeof(random_state.counter)); ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Zeroing sensitive memory chunks [Was: Security Flaw in Popular Disk Encryption Technologies]
On Tue, 26 Feb 2008 22:49:37 +0300 Eygene Ryabinkin [EMAIL PROTECTED] wrote: Yes, Geoff just responded to my private question: it was Peter Gutmann, who pointed him to the thing you're talking about. There is a paper by Peter, http://www.usenix.org/publications/library/proceedings/sec96/full_papers/gutmann/ There's an updated copy of this paper on Gutmann's site that points-out that he was writing about devices that were being decommissioned in the early nineties, and that he's sceptical about anything being recovered from modern drives once they have been overwritten - even once. The idea that that forensic scientists use this kind of technique to recover deleted files is a myth. I still don't understand how cleaning of a memory area will help to clean the swapped page, but may be there are some systems which will update the swapped page on the memory access. That shouldn't be an issue since it's easy to encrypt swap with a one-time key. In FreeBSD you simply append .eli to the swap device name in fstab. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
