Re: MPSAFE VFS -- List of upcoming actions
On Wed, Sep 26, 2012 at 12:02 PM, Harald Schmalzbauer h.schmalzba...@omnilan.de wrote: schrieb Harald Schmalzbauer am 25.09.2012 20:24 (localtime): schrieb Attilio Rao am 21.09.2012 02:22 (localtime): On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao atti...@freebsd.org wrote: On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao atti...@freebsd.org wrote: 2012/7/4 Attilio Rao atti...@freebsd.org: 2012/6/29 Attilio Rao atti...@freebsd.org: As already published several times, according to the following plan: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS I still haven't heard from Vivien or Edward, anyway as NTFS is basically only used RO these days (also the mount_ntfs code just permits RO mounting) I stripped all the uncomplete/bogus write support with the following patch: http://www.freebsd.org/~attilio/ntfs_remove_write.patch This is an attempt to make the code smaller and possibly just focus on the locking that really matter (as read-only filesystem). On some points of the patch I'm a bit less sure as we could easily take into account also write for things like vaccess() arguments, and make easier to re-add correct write support at some point in the future, but still force RO, even if the approach used in the patch is more correct IMHO. As an added bonus this patch cleans some dirty code in the mount operation and fixes a bug as vfs_mountedfrom() is called before real mounting is completed and can still fail. A quick update on this. It looks like NTFS won't be completed for this GSoC thus I seriously need to find an alternative to not loose the NTFS support entirely. I tried to look into the NTFS implementation right now and it is really a poor support. As Peter has also verified, it can deadlock in no-time, it compeltely violates VFS rules, etc. IMHO it deserves a complete rewrite if we would still support in-kernel NTFS. I also tried to look at the NetBSD implementation. Their code is someway similar to our, but they used very complicated (and very dirty) code to do the locking. Even if I don't know well enough NetBSD VFS, I have the impression not all the races are correctly handled. Definitively, not something I would like to port. Considering all that the only viable option would be meaning an userland filesystem implementation. My preferred choice would be to import PUFFS and librefuse on top of it but honestly it requires a lot of time to be completed, time which I don't currently have as in 2 months Giant must be gone by the VFS. I then decided to switch to gnn's rewamp of FUSE patches. You can find his initial e-mail here: http://lists.freebsd.org/pipermail/freebsd-fs/2012-March/013876.html I've precisely got the second version of George's patch and created this dolphin branch: svn://svn.freebsd.org/base/projects/fuse I'm fixing low hanging fruit for the moment (see r238411 for example) and I still have to make a throughful review. However my idea is to commit the support once: - ntfs-3g is well stress-tested and proves to be bug-free - there is no major/big technical issue pending after the reviews In the last weeks Peter, Florian, Gustau and I have been working in stabilizing fuse support. In the specific, Peter has worked hard on producing several utilities to nit stress-test fuse and in particular ntfs, Florian has improved fuse related ports (as explained later) and Gustau has done sparse testing. I feel moderately satisfied by the level of stability of fuse now to propose to wider usage, in particular given the huge amount of complaints I'm hearing around about occasional fuse users. The final target of the project is to completely import into base the content of fusefs-kmod starting from earlier posted patches by George. So far, we took care only of importing in the fuse branch the kernel part, so that fusefs-kmod userland part is still needed to be installed from ports, but I was studying the mount_fusefs licensing before to process with the import for the userland bits of it. The fixing has been happening here: svn://svn.freebsd.org/base/projects/fuse/ which is essentially an HEAD branch + fuse kernel components. In order to get fuse, please compile a kernel from this branch with FUSE option or simply build and load fuse module. Alternatively, a kernel patch that should work with HEAD@240684 is here: http://www.freebsd.org/~attilio/fuse_import/fuse_240684.patch I guess the patch can easilly apply to all FreeBSD branches, really, but it is not tested to anything else different then -CURRENT. As said you still need currently to build fusefs-kmod port. However you need these further patches, to be put in the fusefs-kmod/files/ directory:: http://www.freebsd.org/~attilio/fuse_import/patch-Makefile http://www.freebsd.org/~attilio/fuse_import/patch-mount_fusefs__mount_fusefs2.c They both disable the old kernel building/linking and import new functionality to let the new kernel support work well in presence of
Re: MPSAFE VFS -- List of upcoming actions
schrieb Attilio Rao am 28.09.2012 16:18 (localtime): On Wed, Sep 26, 2012 at 12:02 PM, Harald Schmalzbauer h.schmalzba...@omnilan.de wrote: ... After many people willing to test fuse on STABLE_9, I made this patch that at least compiles there: http://www.freebsd.org/~attilio/fuse_import/fuse_stable9_241030.patch Thanks a lot! In the meantime I made the original patch compiling. I simply looked at the changes which were made around july in the fuse project to follow changes in head (checkpath(), vrecycle() and vtruncbuf()) and reverted them. Since I have no idea about the code I modified, I'm happy that you did a more qualified patch set :-) Of course, I didn't have a chance to test it because I'm also out for vacation right now but please do and report. Happy holiday!!! If you're by chance arround the Oktoberfest, drop me a note, I'll pay you a Maß (or any other drink if you don't like „Wiesnbier“) :-) ... Some questions: Is this planned to be mfc'd and if so, how can one know? In which sense how can one know?. We usually specify MFC timeouts in the commit message (not sure if this answers your concerns). Yep, that's what I wanted to know. So if there's no MFC timeout in the log, it's not intended to be MFCd ever I guess. Thanks a lot! World/Kernel compiled fine in the meantime, I'll do some sshfs tests. -Harry signature.asc Description: OpenPGP digital signature
Re: ZFS on HEAD
On Fri, Sep 28, 2012 at 06:08:41PM +0200, Sami Halabi wrote: I tried to follow: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-zfs.html to recompile the kernel with KVA_PAGES and i couldn't compile. any ideas why this? What was the error? Glen pgpSAFywn5RwW.pgp Description: PGP signature
Re: ZFS on HEAD
/usr/src/sys/amd64/confSAMI: unknown option KVA_PAGES On Fri, Sep 28, 2012 at 6:33 PM, Glen Barber g...@freebsd.org wrote: On Fri, Sep 28, 2012 at 06:08:41PM +0200, Sami Halabi wrote: I tried to follow: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-zfs.html to recompile the kernel with KVA_PAGES and i couldn't compile. any ideas why this? What was the error? Glen -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS on HEAD
On Fri, Sep 28, 2012 at 09:31:41PM +0200, Sami Halabi wrote: On Fri, Sep 28, 2012 at 6:33 PM, Glen Barber g...@freebsd.org wrote: On Fri, Sep 28, 2012 at 06:08:41PM +0200, Sami Halabi wrote: I tried to follow: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-zfs.html to recompile the kernel with KVA_PAGES and i couldn't compile. any ideas why this? What was the error? /usr/src/sys/amd64/confSAMI: unknown option KVA_PAGES KVA_PAGES is not a valid option for amd64 kernel configurations. It is only needed/recommended for i386 and pc98 architectures. Glen pgpHbbrIEcKJU.pgp Description: PGP signature
Re: ZFS on HEAD
got it, I thought amd64 is i386 with 64 bit, seems i was wrong in termenlogy Thanks a lot On Fri, Sep 28, 2012 at 9:36 PM, Glen Barber g...@freebsd.org wrote: On Fri, Sep 28, 2012 at 09:31:41PM +0200, Sami Halabi wrote: On Fri, Sep 28, 2012 at 6:33 PM, Glen Barber g...@freebsd.org wrote: On Fri, Sep 28, 2012 at 06:08:41PM +0200, Sami Halabi wrote: I tried to follow: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-zfs.html to recompile the kernel with KVA_PAGES and i couldn't compile. any ideas why this? What was the error? /usr/src/sys/amd64/confSAMI: unknown option KVA_PAGES KVA_PAGES is not a valid option for amd64 kernel configurations. It is only needed/recommended for i386 and pc98 architectures. Glen -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS on HEAD
On Fri, Sep 28, 2012 at 09:31:41PM +0200 I heard the voice of Sami Halabi, and lo! it spake thus: /usr/src/sys/amd64/confSAMI: unknown option KVA_PAGES You're using amd64, not i386; you don't need to mess with KVA_PAGES. In fact, you probably don't need to tune anything on amd64, unless you've got either very little or very huge physical memory. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS on HEAD
Hi, what count for little, and what count for huge. is there any documented tunings needed for both cases? if not I'd appreciate it much if you explain the tunungs needed and what they do. Sami On Fri, Sep 28, 2012 at 9:37 PM, Matthew D. Fuller fulle...@over-yonder.net wrote: On Fri, Sep 28, 2012 at 09:31:41PM +0200 I heard the voice of Sami Halabi, and lo! it spake thus: /usr/src/sys/amd64/confSAMI: unknown option KVA_PAGES You're using amd64, not i386; you don't need to mess with KVA_PAGES. In fact, you probably don't need to tune anything on amd64, unless you've got either very little or very huge physical memory. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS on HEAD
on 28/09/2012 22:37 Sami Halabi said the following: got it, I thought amd64 is i386 with 64 bit, seems i was wrong in termenlogy Yes, we refer to the general platform as x86. i386 is 32-bit x86 and amd64 is 64-bit x86. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS on HEAD
On Fri, Sep 28, 2012 at 09:44:08PM +0200 I heard the voice of Sami Halabi, and lo! it spake thus: what count for little, and what count for huge. Off the top of my head, I'd say less than 1 gig (maybe 2) or more than 256. With very little, you may need to start looking at some of the i386 tuning to things to scale back. But anywhere in the middle the defaults should work fine (I'm sure there are gains to be had from working at tuning, but probably not huge and probably very dependent on your particular hardware and workloads). -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Call for bge(4) testers
On Thu, 2012-09-27 at 17:09 -0700, Sean Bruno wrote: We have seen 2 instances of one or more of the HP machines failing and dropping off the network. however, we don't have specifics yet. It looks like this specific error was ACPI related, not BGE related. The C6 setting in the BIOS has the nasty side effect of somehow letting CPU's quiesce and become unwakeable. Setting the lowest Cstate in the *bios* to C3 is under test. Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Trying current
Hi list, I'm getting and old core2duo today to install FreeBSD (hopefully current) on it. Looking in the ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ folder for the last week or so, there have been no snapshots in there. Do they still come out roughly monthly and/or is one likely to appear soon? Looking at the instructions at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html , it does not specifically mention a starting point to build from. If not snapshots are expected soon, am I likely to experience much grief in getting from 9.0 or 9.1rc1 to current? Thanks, Brett. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Trying current
Hi, On Sat, Sep 29, 2012 at 10:00:39AM +1000, Brett wrote: Hi list, I'm getting and old core2duo today to install FreeBSD (hopefully current) on it. Looking in the ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ folder for the last week or so, there have been no snapshots in there. Do they still come out roughly monthly and/or is one likely to appear soon? Looking at the instructions at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html , it does not specifically mention a starting point to build from. If not snapshots are expected soon, am I likely to experience much grief in getting from 9.0 or 9.1rc1 to current? I am working on generating regular snapshots. I do not currently have anything official as far as FreeBSD.org goes, but please feel free to try the snapshots I have already created: http://snapshots.glenbarber.us/Latest/ There are i386 and amd64 snapshots for 10-CURRENT and 9-STABLE (not 9.1-RC1). Glen pgpsoMvc0bbSS.pgp Description: PGP signature
Re: ZFS on HEAD
On 2012-09-28 21:49, Matthew D. Fuller wrote: On Fri, Sep 28, 2012 at 09:44:08PM +0200 I heard the voice of Sami Halabi, and lo! it spake thus: what count for little, and what count for huge. Off the top of my head, I'd say less than 1 gig (maybe 2) or more than 256. With very little, you may need to start looking at some of the i386 tuning to things to scale back. But anywhere in the middle the defaults should work fine (I'm sure there are gains to be had from working at tuning, but probably not huge and probably very dependent on your particular hardware and workloads). Just as a measuring point, I managed to run ZFS on an moderately busy FTP server with 2GB while waiting for replacement RAM. It worked, but is perhaps not the best approach. Less than 4 or even 8GB ram is probably not recommended these days, especially since RAM is resonably cheap. Regards! -- Niclas P.S. The handbook should perhaps be slightly updated wrt ZFS, at least to clarify that tuning is only needed on i386 in the general case, and that you're usually better off running ZFS on an amd64 machine if you can choose. I'll look into it tomorrow... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
