Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage?
On Mon, Oct 07, 2013 at 07:34:24PM +0200, 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 gave this patch a spin for 12 hours without finding any problems. I can do more testing at a later time, if you want to. - Peter ___ 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
Fuse on FreeBSD 9.2
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. Thank you, Luke ___ 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?
Hi, Please try it out on a -10 VM with something RAM limited - say, 128mb w/ GENERIC. See how it behaves. I've successfully done buildworlds on 10-i386 with 128mb RAM. Let's try not to break that before releng/10 is cut. thanks, -adrian On 7 October 2013 23:34, Peter Holm pe...@holm.cc wrote: On Mon, Oct 07, 2013 at 07:34:24PM +0200, 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 gave this patch a spin for 12 hours without finding any problems. I can do more testing at a later time, if you want to. - Peter ___ 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 ___ 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, 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. I've successfully done buildworlds on 10-i386 with 128mb RAM. Let's try not to break that before releng/10 is cut. thanks, 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. Previous changes in this area just did the opposite keeping a lot more of memory around. I hope this makes sense to you. Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: Fuse on FreeBSD 9.2
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
Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage?
On Tue, Oct 8, 2013 at 1:32 PM, Davide Italiano dav...@freebsd.org 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. I've successfully done buildworlds on 10-i386 with 128mb RAM. Let's try not to break that before releng/10 is cut. thanks, 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. Previous changes in this area just did the opposite keeping a lot more of memory around. I hope this makes sense to you. Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare Also, right now you can set up a value which indicates the percentage of memory you can reclaim. It's 10% by default, but we can discuss if this could be adjusted to a more reasonable default. Feel free to give your opinion. -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: Fuse on FreeBSD 9.2
On Tue, Oct 8, 2013, at 6:34, Mark Felder wrote: 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? Well actually the description on the WhatsNew/FreeBSD10 page has me on the fence about whether or not the port and the new module in FreeBSD 10 share the same source. You could diff it to find out. I'm a bit short on time this morning to dig into that. :-) The FreeBSD port (including the clean-room BSD-licenced reimplementation of the kernel module) was created during 2 summer of code mandates and being revived by gnn recently. The functionality in this commit matches the content of fusefs-kmod port, which doesn't need to be installed anymore for -CURRENT setups. https://wiki.freebsd.org/WhatsNew/FreeBSD10 ___ 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: Fuse on FreeBSD 9.2
On Tue, 8 Oct 2013 14:08:41 +0200 Łukasz P ad...@3dr.org wrote: Thank you - I'll give it a try today. Can you confirm that doing rsync with this fuse version is stable? I'm sorry but I've never even tried rsync on top of a fuse mount. Can you please tell us which fuse-based file system have you used? Mostly sysutils/fusefs-smbnetfs to access file servers and sometimes sysutils/fusefs-ntfs with Win XP and Win 7 disks. -- 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: Fuse on FreeBSD 9.2
Thank you! -Original Message- From: Yamagi Burmeister [mailto:li...@yamagi.org] Sent: Tuesday, October 08, 2013 2:14 PM To: ad...@3dr.org Cc: f...@freebsd.org; freebsd-hackers@freebsd.org Subject: Re: Fuse on FreeBSD 9.2 On Tue, 8 Oct 2013 14:08:41 +0200 Łukasz P ad...@3dr.org wrote: Thank you - I'll give it a try today. Can you confirm that doing rsync with this fuse version is stable? I'm sorry but I've never even tried rsync on top of a fuse mount. Can you please tell us which fuse-based file system have you used? Mostly sysutils/fusefs-smbnetfs to access file servers and sometimes sysutils/fusefs-ntfs with Win XP and Win 7 disks. -- 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: ZFS Boot Menu
06.10.2013 08:54, Teske, Devin wrote: On Sep 30, 2013, at 6:20 AM, Volodymyr Kostyrko wrote: 29.09.2013 00:30, Teske, Devin wrote: Interested in feedback, but moreover I would like to see who is interested in tackling this with me? I can't do it alone... I at least need testers whom will provide feedback and edge-case testing. Sign me in, I'm not fluent with forth but testing something new is always fun. Cool; to start with, do you have a virtual appliance software like VMware or VirtualBox? Experience with generating ZFS pools in said software? VirtualBox/Qemu, Qemu is able to emulate boot to serial for example. And yes I tried working with ZFS in VMs. I think that we may have something to test next month. Right now, we're working on the ability of bsdinstall(8) to provision Boot on ZFS as a built-in functionality. That sounds cool. -- Sphinx of black quartz, judge my vow. ___ 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: Fuse on FreeBSD 9.2
On Tue, Oct 8, 2013, at 7:08, Łukasz P wrote: Thank you - I'll give it a try today. Can you confirm that doing rsync with this fuse version is stable? Can you please tell us which fuse-based file system have you used? My main use case these days is ntfs-3g, and I no longer get panics when doing mass file operations including rsync. :-) ___ 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: 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: Fuse on FreeBSD 9.2
Responding to myself... On Tue, 8 Oct 2013 14:13:35 +0200 Yamagi Burmeister li...@yamagi.org wrote: On Tue, 8 Oct 2013 14:08:41 +0200 Łukasz P ad...@3dr.org wrote: Thank you - I'll give it a try today. Can you confirm that doing rsync with this fuse version is stable? I'm sorry but I've never even tried rsync on top of a fuse mount. I've just rsynced ~25GB data from an smbnetfs mount to zfs and back to the smbnetfs mount. No problems so far. That's of course only a first test but apparently there are no obvious problems / panics. -- 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: Fuse on FreeBSD 9.2
Sounds good - I'm using MooseFS file system - and problems with fuse occurs during rsync. I will test suggested by you http://people.freebsd.org/~flo/fusefs-kmod.tar.bz2 - and will let know if that works in few hours. -Original Message- From: Yamagi Burmeister [mailto:li...@yamagi.org] Sent: Tuesday, October 08, 2013 2:59 PM To: ad...@3dr.org Cc: freebsd-hackers@freebsd.org Subject: Re: Fuse on FreeBSD 9.2 Responding to myself... On Tue, 8 Oct 2013 14:13:35 +0200 Yamagi Burmeister li...@yamagi.org wrote: On Tue, 8 Oct 2013 14:08:41 +0200 Łukasz P ad...@3dr.org wrote: Thank you - I'll give it a try today. Can you confirm that doing rsync with this fuse version is stable? I'm sorry but I've never even tried rsync on top of a fuse mount. I've just rsynced ~25GB data from an smbnetfs mount to zfs and back to the smbnetfs mount. No problems so far. That's of course only a first test but apparently there are no obvious problems / panics. -- 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: Fuse on FreeBSD 9.2
Thank you - I'll give it a try today. Can you confirm that doing rsync with this fuse version is stable? Can you please tell us which fuse-based file system have you used? 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: 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: Call fo comments - raising vfs.ufs.dirhash_reclaimage?
On Tue, Oct 8, 2013 at 3:38 PM, RW rwmailli...@googlemail.com wrote: 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. Hi (RW..?), 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. 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. 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. Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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
