RE: Fuse on FreeBSD 9.2
Hello, I've tried http://people.freebsd.org/~flo/fusefs-kmod.tar.bz2 on 9.2 - unfortunatelly - there's the same problem as with fuse from 10. While using MooseFS filesystem changes made on one client node are not visible to other clients. It's like the file content is not being refreshed. There is no such problem on 7.4 or 8.4 using regular fusefs-kmod from ports. Luke -Original Message- From: Yamagi Burmeister [mailto:li...@yamagi.org] Sent: Tuesday, October 08, 2013 2:03 PM To: f...@freebsd.org Cc: freebsd-hackers@freebsd.org; ad...@3dr.org Subject: Re: Fuse on FreeBSD 9.2 There's already a backport which can be found here: http://people.freebsd.org/~flo/fusefs-kmod.tar.bz2 1. Download, untar and replace your existing sysutils/fusefs-kmod port with it. Open the Makefile and add NO_STAGE= yes to it. 2. cd sysutils/fusefs-kmod ; make makesum ; make deinstall reinstall clean 4. Rebuild sysutils/fusefs-libs and all fuse filesystems (don't know if that's necessary but it doesn't hurt either). I've been running with this kernel module on FreeBSD 9-STABLE, 9.1 and 9.2 four about one year without any problem. I don't know why flo@ never committed his work. On Tue, 08 Oct 2013 06:34:03 -0500 Mark Felder f...@freebsd.org wrote: On Tue, Oct 8, 2013, at 5:21, Łukasz P wrote: Hello, Please let me know if anyone is up to fix fuse on FreeBSD 9.x ? Particularly this bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=182739 http://www.freebsd.org/cgi/query-pr.cgi?pr=182739 I'm willing to pay for the fix. I think the fix is the new from-scratch fuse module in FreeBSD 10, which in my experience works flawlessly. Perhaps you should instead see if someone is willing to backport that fuse module to 9.x? ___ 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 -- Homepage: www.yamagi.org XMPP: yam...@yamagi.org GnuPG/GPG: 0xEFBCCBCB ___ 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: openjdk7 dtrace support
On Thursday, October 10, 2013 12:07 PM, Mark Johnston ma...@freebsd.org wrote: On Wed, Oct 09, 2013 at 09:55:51PM +0800, Patrick Dung wrote: Hello, I would like to know it there is dtrace support in the openjdk7? Not yet on FreeBSD, unless there's something I'm missing. Some work needs to be done on the port in order to get it working. hotspot/make/bsd/makefiles/dtrace.make only does anything if it detects that it's running on Darwin; that'd probably be a good place to start for anyone interested in working on this. -Mark Hi Mark, Noted and thanks. The Postgresql port (9.3, not sure for 8.4/9.1/9.2) have dtrace support, which is very cool. Thanks, Patrick ___ 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: What's the state of AF-4Kn support?
On Monday, September 23, 2013 10:58:19 am Ravi Pokala wrote: -Original Message- From: Jia-Shiun Li jiash...@gmail.com Date: Sunday, September 22, 2013 11:22 PM To: Ravi Pokala rp_free...@mac.com Cc: freebsd-hardw...@freebsd.org freebsd-hardw...@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: What's the state of AF-4Kn support? On Wed, Sep 18, 2013 at 10:49 PM, Ravi Pokala rp_free...@mac.com wrote: ... CC -hackers. Thanks for the clarification. Is there any 4Kn HDDs shopping now? I am not aware of any. Good question. I had the impression that some currently shipping drives were AF-4Kn, but spot-checking some of the drives listed in src/cam/ata/ata_da.c::ada_quirk_table[] against their datasheets, suggests that they're AF-512e. So, their being flagged w/ ADA_Q_4K is just a performance optimization. BTW I believe UFS and ZFS have proper design for 4K-sectors, but FreeBSD needs some ecosystem connections to get samples early to test, incorporate supports and validate for it. Or we will need to wait until it appears on market and someone got caught into some kind of bugs. Yeah, based on my reading of the code, it looks like the ATACAM layer and higher (GEOM, filesystems) take the physical block size into account. That just leaves the bootstrap code. Now that I've taken a second look, it seems as though at least 'pmbr' only works in terms of 512 bytes. :-( Yes, the BIOS calls have always only used 512 byte sectors. There would have to be an updated spec for those, and it would be a bit of a PITA to use. I suspect the right answer for this on x86 is UEFI. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage?
On Monday, October 07, 2013 1:34:24 pm Davide Italiano wrote: What would perhaps be better than a hardcoded reclaim age would be to use an LRU-type approach and perhaps set a target percent to reclaim. That is, suppose you were to reclaim the oldest 10% of hashes on each lowmem call (and make the '10%' the tunable value). Then you will always make some amount of progress in a low memory situation (and if the situation remains dire you will eventually empty the entire cache), but the effective maximum age will be more dynamic. Right now if you haven't touched UFS in 5 seconds it throws the entire thing out on the first lowmem event. The LRU-approach would only throw the oldest 10% out on the first call, but eventually throw it all out if the situation remains dire. -- John Baldwin ___ freebsd...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to freebsd-fs-unsubscr...@freebsd.org I liked your idea more than what's available in HEAD right now and I implemented it. http://people.freebsd.org/~davide/review/ufs_direclaimage.diff I was unsure what kind of heuristic I should choose to select which (10% of) entries should be evicted so I just removed the first 10% ones from the head of the ufs_dirhash list (which should be the oldest). The code keeps rescanning the cache until 10% (or, the percentage set via SYSCTL) of the entry are freed, but probably we can discuss if this limit could be relaxed and just do a single scan over the list. Unfortunately I haven't a testcase to prove the effectiveness (or non-effectiveness) of the approach but I think either Ivan or Peter could be able to give it a spin, maybe. I think this looks good. One cosmetic nit is that I think this: if (!try_lock()) continue; else memfreed += ufsdirhash_destroy(); Looks a bit odd. I would either drop the else (which the old code did in its failsafe case) or just do this: if (try_lock()) memfreed += ufsdirhash_destroy(); -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: mmap() question
On Wed, Oct 09, 2013 at 03:42:27PM +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. But this is not the case. I use the following simple program which gets list of files as command line arguments, mmap()s them all and then selects random file and random 1K parts of that file and computes a XOR of bytes from that region. After some time the program dies: pid 63251 (a.out), uid 1232, was killed: out of swap space 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. You did not specified several very important parameters for your test: 1. total amount of RAM installed 2. count of the test files and size of the files 3. which filesystem files are located at 4. version of the system. pgpu_xJMm2QsF.pgp Description: PGP signature
