Date: Wed, 10 Oct 2012 15:51:13 +0100 From: Attilio Rao <attilio@freebsd.org> To: Kevin Oberman <kob6558@gmail.com> Cc: FreeBSD FS <freebsd-fs@freebsd.org>, Harald Schmalzbauer <h.schmalzbauer@omnilan.de>, freebsd-current@freebsd.org Subject: Re: MPSAFE VFS -- List of upcoming actions Message-ID: <CAJ-FndAJfH5niv=E33ysoqe8i=LOZdhtZPrV5ZRqZdfbruBM=w@mail.gmail.com> In-Reply-To: <CAN6yY1ur1fy01wnig3LEhf6mr3_aRnyAmQYANjXy6UxgakOiqg@mail.gmail.com> References: <CAJ-FndCQ0YEo9_6x3g-12XEs8QmtyecwkLBX9z_sptnOUNTHrw@mail.gmail.com> <20120829060158.GA38721@x2.osted.lan> <CAJ-FndAaFv2o05MZZceT8Qr4mhPxuzrnmOZ30c3gy8=pnjjZvw@mail.gmail.com> <20120831052003.GA91340@x2.osted.lan> <CAJ-FndAaxQA8NYCFSN629XXi9zMVNyu2TuHjZLvmn3jhzRJb4w@mail.gmail.com> <CAJ-FndDdDVuwc=NgDeG7XiWW59-%2BLs5wc2GBqbjLOLDUdUb9SA@mail.gmail.com> <20120905201531.GA54452@x2.osted.lan> <CAJ-FndCHSroZFfVgHAW8SUVZhDSaX9qix=aZnHVC_BN_fW6sgg@mail.gmail.com> <CAJ-FndDr5WmeKXCwSCucQ4w3hPHRBuu36YH1xiW_wKXOkKEdZg@mail.gmail.com> <CAJ-FndCvc%2BphY_g4CeGfzsj017roxs_C5adjuLuszpEPWO2%2B1g@mail.gmail.com> <20120917140055.GA9037@x2.osted.lan> <CAJ-FndAP9Ua6tRcbrfYY1%2B56O-YbJvmyaUco9K42-0hmchKD6g@mail.gmail.com> <CAJ-FndAisKoCwLkvXpmW=XhXDRH8me8fMjwrfBuWVqfoA95rmQ@mail.gmail.com> <5061F6E9.6030104@omnilan.de> <5062E0DE.70805@omnilan.de> <CAJ-FndDhKKwydztGCWL71PKdoKkih7aBYCG89KVa2KZEkpBGeg@mail.gmail.com> <5065B873.4070509@omnilan.de> <CAJ-FndABRZMz_H7aCP0Ci4rur7JqSSSA9=E1GE%2BXofJG=BERaA@mail.gmail.com> <CAN6yY1ur1fy01wnig3LEhf6mr3_aRnyAmQYANjXy6UxgakOiqg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 10, 2012 at 6:15 AM, Kevin Oberman <kob6558@gmail.com> wrote: > On Mon, Oct 8, 2012 at 7:57 AM, Attilio Rao <attilio@freebsd.org> wrote: >> On Fri, Sep 28, 2012 at 4:47 PM, Harald Schmalzbauer >> <h.schmalzbauer@omnilan.de> wrote: >>> schrieb Attilio Rao am 28.09.2012 16:18 (localtime): >>>> On Wed, Sep 26, 2012 at 12:02 PM, Harald Schmalzbauer >>>> <h.schmalzbauer@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=C3=9F (or any other drink if you don't like >>> =E2=80=9EWiesnbier=E2=80=9C) :-) >> >> I really hoped to make this year, but no luck :/ >> >>>>> ... >>>>> Some questions: Is this planned to be mfc'd and if so, how can one kn= ow? >>>> 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. >> >> Did you do any test in the end? >> >> Thanks, >> Attilio > > i have done same testing and it clearly is more stable than the old > kmod. At least operations that crashed my system now work. > > I did see one weird anomaly, though. I had several NTFS file system > mounted, one a Windows OS. I also had a GELI encrypted UFS file system > mounted. They were both mounted and working. I finished with the data > disk and tried to unmount it. I got no error, but it remained mounted. > I did not actually try to access it. Figured it would umount when I > shut down or end up dirty and I'd have to fsck it. The unmount attempt > was using nautilus/gnome-mount. This is not the odd part, though. > > After the attempt to unmount the UFS device, I could no longer access > the Window_OS file system. an ls showed the mount point to be > d--------- and an attempt to list files in the directory reported that > the socket was not found. So it looks like the attempt to unmount one > NTFS FS deleted the socket for the other. > > This make absolutely no sense to me, but you understand the underlying > opertations better than I do. Repeated efforts have failed to > re-create the problem. I'm baffled. It is possible that there is no > relationship between the two odd things happening at about the same > time (NTFS volume lost socket and UFS disk won;t unmount, but reports > no errors), but neither has happened since. > > FWIW, I also see that no device numbers are listed for the fuse devices: > /dev/fuse 184319948 165594236 18725712 90% /media/Media > /dev/fuse 110636028 82934424 27701604 75% /media/Windows7_OS > > How does the system distinguish between them? Sorry, forgot to reply about this and it is due: differently from fuse4bsd version, this one doesn't do device cloning but uses devfs*cdevpriv() infrastructure. So effectively different filedescriptors are handled internally. This is why it requires further changes to the mount_fusefs(8) (because the vfs_mount operation also need further knowledge on the per-filedescriptor handle and it cannot acquire it easilly because it is not a devfs operation). Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndAJfH5niv=E33ysoqe8i=LOZdhtZPrV5ZRqZdfbruBM=w>