Re: top -n -o res shows empty output
Thank you. I’ll take it. > 2018/07/18 18:34、Ali Abdallah のメール: > > I have submitted a bug report with a patch > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229842 > > Best, > Ali > > On Tue, Jul 17, 2018 at 1:41 PM Ali Abdallah wrote: > >> Hello, >> >> From around the revision r334918, the command 'top -n -o res' shows empty >> output. >> >> With best regards, >> Ali >> > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Mellanox Technologies : ConnectX-3 VPI
I am wondering if FreeBSD 10-CURRNET could use Mellanox Technologies's ConnectX-3 VPI infiniband devices. Is there anyone who are using ConnectX-3 VPI with FreeBSD? -- Daichi GOTO (daichi) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: DTrace on FreeBSD
On Tue, 10 Apr 2012 23:14:07 +0100 Sevan / Venture37 ventur...@gmail.com wrote: On 10/04/2012 02:45, Daichi GOTO wrote: Hi, From the DTrace tutorial at AsiaBSDCon 2012, it is a CDDL license issue. Hi Daichi, I wonder which clause/aspect of the license is a problem? I do not know well. And I think Tod McQuillin could help you. (http://2012.asiabsdcon.org/timetable.html#T1B) We've been distributing dtrace as part of our source since FreeBSD 7.1 so the terms of license must have been acceptable for inclusion in our tree redistribution in source for each release since. I've been reading the CCDL license just now clause 3.5 on Distribution of executable vesions states You may distribute the Executable form of the Covered Software under the terms of this License or under the terms of a license of Your choice, which may contain terms different from this License, provided that You are in compliance with the terms of this License and that the license for the Executable form does not attempt to limit or alter the recipient’s rights in the Source Code form from the rights set forth in this License. If You distribute the Covered Software in Executable form under a different license, You must make it absolutely clear that any terms which differ from this License are offered by You alone, not by the Initial Developer or Contributor. You hereby agree to indemnify the Initial Developer and every Contributor for any liability incurred by the Initial Developer or such Contributor as a result of any such terms You offer. This shouldn't pose any legal problems for the project if DTrace was redistributed in binary form should it? Addition from my experiences, some applicaions can not be built on DTrace/UserlandDTrace-enabled system (VBox is) and Userland dtrace is still unstable. I see, was the virtual box issue recently, I'm pretty sure I was able to build virtual box on a DTrace enabled system in the past couple of months. You did? I'm so jealous! Sevan ___ 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 -- Daichi GOTO (daichi) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: DTrace on FreeBSD
Hi, From the DTrace tutorial at AsiaBSDCon 2012, it is a CDDL license issue. Addition from my experiences, some applicaions can not be built on DTrace/UserlandDTrace-enabled system (VBox is) and Userland dtrace is still unstable. On Tue, 10 Apr 2012 02:18:38 +0100 Sevan / Venture37 ventur...@gmail.com wrote: Hi, Ryan Stone got a chance to give a brief talk at the dtrace.conf last week where he covered the status of support on FreeBSD. http://smartos.org/2012/04/09/dtrace-conf-2012-dtrace-on-freebsd/ I was wondering if the reason outlined by Ryan for why it DTrace isn't switched on by default still hold true (licensing issue) or is it just the case that it was forgotten about? I ask as It would be nice to have DTrace on FreeBSD by default. Sevan___ 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 -- Daichi GOTO (daichi) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: (unionfs) panic: excl-share with r230341 and above
Thanks kwhite,
I found an another lock issue. Please try a patch included.
On Mon, 9 Apr 2012 10:31:39 -0400 (EDT)
kwh...@site.uottawa.ca wrote:
Hi
Please try an attached patch that improves handlings of fs locks.
I think that this patch can resolve this issue. If that works well,
I'm going to refine and commit it to head.
Thanks!
I tried your patch but get the same panic:
FreeBSD 10.0-CURRENT #6 r233856M: Mon Apr 9 09:47:42 EDT 2012
...
exclusive lock of (lockmgr) ufs @
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1897
while share locked from /usr/src/sys/modules/unionfs/../../fs/unionfs/
union_vnops.c:1897
panic: excl-share
cpuid = 0
KDB: enter: panic
[ thread pid 38 tid 100050 ]
Stopped at kdb_enter+0x3b: movl$0,kdb_why
db show all locks
Process 38 (ls) thread 0xc56dd2e0 (100050)
exclusive sleep mutex vnode interlock (vnode interlock) r = 0
(0xc5797d38) locked @
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1889
shared lockmgr ufs (ufs) r = 0 (0xc5797d18) locked @
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1897
db
On Fri, 6 Apr 2012 21:36:29 -0400 (EDT)
kwh...@site.uottawa.ca wrote:
Starting with r230341, I get the following panic when trying to run
an executable on a unionfs filesystem:
exclusive lock of (lockmgr) ufs @
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843
while share locked from
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843
panic: excl-share
cpuid = 0
KDB: enter: panic
Narrowing down with a binary search: r230340 (no panic), r230341
(panic).
How to repeat:
# uuname -a
FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r233946M: Fri Apr
6
21:09:32 EDT 2012 kwhite@demo:/usr/src/obj/usr/src/sys/GENERIC
i386
# mkdir /tmp/local
# mount -t unionfs -o noatime /tmp/local /usr/local
# cp /bin/ls /usr/local/bin/ls
# /usr/local/bin/ls
exclusive lock of (lockmgr) ufs @
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843
while share locked from
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843
panic: excl-share
cpuid = 0
KDB: enter: panic
[ thread pid 68 tid 100054 ]
Stopped at kdb_enter+0x3b: movl$0,kdb_why
db show all locks
Process 68 (ls) thread 0xc578 (100054)
exclusive sleep mutex vnode interlock (vnode interlock) r = 0
(0xc57cec28) locked @
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1835
shared lockmgr ufs (ufs) r = 0 (0xc57cec08) locked @
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843
db
Workaround?
After reverting the change from LK_EXCLUSIVE to LK_SHARED
in sys/kern/kern_exec.c, executables on union filesystems no
longer cause a panic.
...keith
___
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
--
Daichi GOTO (daichi)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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
--
Daichi GOTO (daichi)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
diff -urBN /usr/src.orig/sys/fs/unionfs/union_subr.c /usr/src/sys/fs/unionfs/union_subr.c
--- /usr/src.orig/sys/fs/unionfs/union_subr.c 2012-04-08 14:01:23.0 +0900
+++ /usr/src/sys/fs/unionfs/union_subr.c 2012-04-10 02:22:38.0 +0900
@@ -350,19 +350,22 @@
uvp = unp-un_uppervp;
dvp = unp-un_dvp;
unp-un_lowervp = unp-un_uppervp = NULLVP;
-
vp-v_vnlock = (vp-v_lock);
vp-v_data = NULL;
- lockmgr(vp-v_vnlock, LK_EXCLUSIVE | LK_INTERLOCK, VI_MTX(vp));
+ vp-v_object = NULL;
+ VI_UNLOCK(vp);
+
if (lvp != NULLVP)
- VOP_UNLOCK(lvp, 0);
+ VOP_UNLOCK(lvp, LK_RELEASE);
if (uvp != NULLVP)
- VOP_UNLOCK(uvp, 0);
- vp-v_object = NULL;
+ VOP_UNLOCK(uvp, LK_RELEASE);
if (dvp != NULLVP unp-un_hash.le_prev != NULL)
unionfs_rem_cached_vnode(unp, dvp);
+ if (lockmgr(vp-v_vnlock, LK_EXCLUSIVE, VI_MTX(vp)) != 0)
+ panic(the lock for deletion is unacquirable.);
+
if (lvp != NULLVP) {
vfslocked = VFS_LOCK_GIANT(lvp-v_mount);
vrele(lvp);
@@ -550,7 +553,7 @@
cn-cn_flags |= (cnp-cn_flags SAVESTART);
vref(dvp);
- VOP_UNLOCK(dvp, 0);
+ VOP_UNLOCK(dvp, LK_RELEASE);
if ((error = relookup(dvp, vpp, cn))) {
uma_zfree(namei_zone, cn-cn_pnbuf);
@@ -957,7 +960,7 @@
*vpp = vp
Re: (unionfs) panic: excl-share with r230341 and above
Hi
Please try an attached patch that improves handlings of fs locks.
I think that this patch can resolve this issue. If that works well,
I'm going to refine and commit it to head.
On Fri, 6 Apr 2012 21:36:29 -0400 (EDT)
kwh...@site.uottawa.ca wrote:
Starting with r230341, I get the following panic when trying to run
an executable on a unionfs filesystem:
exclusive lock of (lockmgr) ufs @
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843
while share locked from
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843
panic: excl-share
cpuid = 0
KDB: enter: panic
Narrowing down with a binary search: r230340 (no panic), r230341 (panic).
How to repeat:
# uuname -a
FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r233946M: Fri Apr 6
21:09:32 EDT 2012 kwhite@demo:/usr/src/obj/usr/src/sys/GENERIC
i386
# mkdir /tmp/local
# mount -t unionfs -o noatime /tmp/local /usr/local
# cp /bin/ls /usr/local/bin/ls
# /usr/local/bin/ls
exclusive lock of (lockmgr) ufs @
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843
while share locked from
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843
panic: excl-share
cpuid = 0
KDB: enter: panic
[ thread pid 68 tid 100054 ]
Stopped at kdb_enter+0x3b: movl$0,kdb_why
db show all locks
Process 68 (ls) thread 0xc578 (100054)
exclusive sleep mutex vnode interlock (vnode interlock) r = 0
(0xc57cec28) locked @
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1835
shared lockmgr ufs (ufs) r = 0 (0xc57cec08) locked @
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843
db
Workaround?
After reverting the change from LK_EXCLUSIVE to LK_SHARED
in sys/kern/kern_exec.c, executables on union filesystems no
longer cause a panic.
...keith
___
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
--
Daichi GOTO (daichi)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
diff -urBN /usr/src.orig/sys/fs/unionfs/union_subr.c /usr/src/sys/fs/unionfs/union_subr.c
--- /usr/src.orig/sys/fs/unionfs/union_subr.c 2012-04-08 12:31:30.0 +0900
+++ /usr/src/sys/fs/unionfs/union_subr.c 2012-04-08 12:43:04.0 +0900
@@ -350,19 +350,22 @@
uvp = unp-un_uppervp;
dvp = unp-un_dvp;
unp-un_lowervp = unp-un_uppervp = NULLVP;
-
vp-v_vnlock = (vp-v_lock);
vp-v_data = NULL;
- lockmgr(vp-v_vnlock, LK_EXCLUSIVE | LK_INTERLOCK, VI_MTX(vp));
+ vp-v_object = NULL;
+ VI_UNLOCK(vp);
+
if (lvp != NULLVP)
- VOP_UNLOCK(lvp, 0);
+ VOP_UNLOCK(lvp, LK_RELEASE);
if (uvp != NULLVP)
- VOP_UNLOCK(uvp, 0);
- vp-v_object = NULL;
+ VOP_UNLOCK(uvp, LK_RELEASE);
if (dvp != NULLVP unp-un_hash.le_prev != NULL)
unionfs_rem_cached_vnode(unp, dvp);
+ if (lockmgr(vp-v_vnlock, LK_EXCLUSIVE, VI_MTX(vp)) != 0)
+ panic(the lock for deletion is unacquirable.);
+
if (lvp != NULLVP) {
vfslocked = VFS_LOCK_GIANT(lvp-v_mount);
vrele(lvp);
@@ -550,7 +553,7 @@
cn-cn_flags |= (cnp-cn_flags SAVESTART);
vref(dvp);
- VOP_UNLOCK(dvp, 0);
+ VOP_UNLOCK(dvp, LK_RELEASE);
if ((error = relookup(dvp, vpp, cn))) {
uma_zfree(namei_zone, cn-cn_pnbuf);
@@ -957,7 +957,7 @@
*vpp = vp;
unionfs_vn_create_on_upper_free_out1:
- VOP_UNLOCK(udvp, 0);
+ VOP_UNLOCK(udvp, LK_RELEASE);
unionfs_vn_create_on_upper_free_out2:
if (cn.cn_flags HASBUF) {
diff -urBN /usr/src.orig/sys/fs/unionfs/union_vfsops.c /usr/src/sys/fs/unionfs/union_vfsops.c
--- /usr/src.orig/sys/fs/unionfs/union_vfsops.c 2012-04-08 12:31:30.0 +0900
+++ /usr/src/sys/fs/unionfs/union_vfsops.c 2012-04-08 12:43:04.0 +0900
@@ -165,7 +165,7 @@
uid = va.va_uid;
gid = va.va_gid;
}
- VOP_UNLOCK(mp-mnt_vnodecovered, 0);
+ VOP_UNLOCK(mp-mnt_vnodecovered, LK_RELEASE);
if (error)
return (error);
@@ -250,7 +250,7 @@
* Save reference
*/
if (below) {
- VOP_UNLOCK(upperrootvp, 0);
+ VOP_UNLOCK(upperrootvp, LK_RELEASE);
vn_lock(lowerrootvp, LK_EXCLUSIVE | LK_RETRY);
ump-um_lowervp = upperrootvp;
ump-um_uppervp = lowerrootvp;
@@ -281,7 +281,7 @@
/*
* Unlock the node
*/
- VOP_UNLOCK(ump-um_uppervp, 0);
+ VOP_UNLOCK(ump-um_uppervp, LK_RELEASE);
/*
* Get the unionfs root vnode.
diff -urBN /usr/src.orig/sys/fs/unionfs/union_vnops.c /usr/src/sys/fs/unionfs/union_vnops.c
--- /usr/src.orig/sys/fs/unionfs/union_vnops.c 2012-04-08 12:31:30.0 +0900
+++ /usr/src/sys/fs/unionfs/union_vnops.c 2012-04-08 12:43:04.0 +0900
@@ -75,21 +75,6 @@
KASSERT(((vp)-v_op == unionfs_vnodeops), \
(unionfs: it is not unionfs-vnode))
-/* lockmgr lock - reverse table
[Call for Test] unionfs intermediate umount feature
Hi unionfs users ;) We have developed new unionfs feature, intermediate umount. You can do like this: # mount_unionfs /test2 /test1 # mount_unionfs /test3 /test1 # df above:/test2 x x x xx% /test1 above:/test3 x x x xx% /test1 # umount 'above:/test2' # df above:/test3 x x x xx% /test1 # patch for current: http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-intermediate-umount.diff First, I want to know your opinion. Thanks :) - Daichi GOTO___ 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
RFC: unionfs multiple mounts, cross mounts and recursive mounts limits and manegement feature
Hi unionfs lovers, It is possible to mount unionfs multiple times more than once at a mount point. However, exceeding multiple mounts could consume kernel stack over its limits and lead a system panic easily. Some users reported that they got a system panic by multiple unionfs mounts. So I make a preproduction prototype to check multiple mounts, cross mounts, recursive mounts and the combination of those of unionfs and prevent that situation. http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-cross-mount3.diff It is adjustable with sysctl value 'vfs.unionfs.recursive_limit' as multiple mounts limits. The default value is 1 and it means two-layered ok. Max value of 'vfs.unionfs.recursive_limit' is 8, it is heuristic value. I couldn't get a system panic unless 'vfs.unionfs.recursive_limit' is over 8. Test reports, suggestions and new patches are always welcome. I'm considering to get merged into current if there are no issues and problems. -- Daichi GOTO ___ 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: RFC: unionfs multiple mounts, cross mounts and recursive mounts limits and manegement feature
On Thu, 21 Apr 2011 11:03:30 +0400 Alex Zimnitsky aa...@yandex.ru wrote: On Thu, 2011-04-21 at 14:49 +0900, Daichi GOTO wrote: It is adjustable with sysctl value 'vfs.unionfs.recursive_limit' as multiple mounts limits. The default value is 1 and it means two-layered ok. Max value of 'vfs.unionfs.recursive_limit' is 8, it is heuristic value. I couldn't get a system panic unless 'vfs.unionfs.recursive_limit' is over 8. Hmm, 8 is not enough for me, i need more :) On the other hand, why do we need recursion in unionfs_statfs at all? IMHO recursion in kernel is evil because it has a potencial of resource exhaustion. This recursion in unionfs_statfs is used to gather statistic (some of which is faked according to comments in the procedure) why not replace recursion with cycle? (I'm not skilled enough do do that :) Exactly. It is one of possible plans to reduce kernel stack consumption except rewriting all relative recursive code into loop treatment is slow work to complete. Rewritten into loop treatment is the next step for our unionfs implementation ;) If rewritten completed, eventually we need some general fs-to-fs communication framework to detect situation comprehensively and prevent kernel stack consumption by multiple mounts of the combination of unionfs and loopback filesystem (especially for nullfs at this time). At this moment, there is no way to communitate with other loopback filesystem from unionfs, so unionfs cannot detect kernel stack consumption situation and prevent a system panic. In follow situation, unionfs cannot detect situation comprehensively and it could lead a system panic by exceeding kernel stack consumption. unionsf - nullfs - unionfs - nullfs - unionfs - nullfs ... and a feature request: it would be great if it was possible to umount one of multiple unionfs: mount -t unionfs /var/ftpdata1 /var/ftp mount -t unionfs /var/ftpdata2 /var/ftp how to unmount /var/ftpdata1 only? I understand how you feel. It is possible to implement. Apparently intermediate unionfs unmount feature is curious and convenience. To implement intermediate unionfs unmount, first we should discuss and define how treats whiteout of intermediate unionfs. Got any ideas? -- Daichi GOTO ___ 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: fcntl always fails to delete lock file, and PID is always -6464
Sent from my iPad On Oct 11, 2010, at 5:50 PM, John Baldwin j...@freebsd.org wrote: On Tuesday, October 05, 2010 2:39:26 am Daichi GOTO wrote: Next step discussion engaged from this research I guess. Should we do change FreeBSD's fcntl(2) to return correct l_pid when called with F_SETLK? Or keep current behavior?? I want to hear other developers ideas and suggetions. POSIX doesn't say that F_SETLK returns a valid l_pid, so I think FreeBSD's current behavior is fine. Yes, I agree. POSIX says so. -- John Baldwin ___ 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: fcntl always fails to delete lock file, and PID is always -6464
On Oct 5, 2010, at 4:52 PM, Garrett Cooper wrote: On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO dai...@ongs.co.jp wrote: On Tue, 5 Oct 2010 01:23:02 -0700 Garrett Cooper gcoo...@freebsd.org wrote: 2010/10/4 Daichi GOTO dai...@ongs.co.jp: Thanks nice test tool :) And at last I got it excepting one mystery! On Mon, 4 Oct 2010 20:17:08 -0700 Garrett Cooper gcoo...@freebsd.org wrote: Following through the same process on FreeBSD... Window 1: $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory $ ./test_fcntl Window 2: $ ls -l /tmp/lockfile -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile $ ./test_fcntl test_fcntl: fcntl: Resource temporarily unavailable Just my mystery is as follow: Windows 1: % ./test_fcntl My pid: 43490 Windows 2: % ls -l /tmp/lockfile -r-sr-x--- 1 daichi wheel 0 10月 5 15:02 /tmp/lockfile--- is it weird, isn't it? % ./test_fcntl test_fcntl: open: Permission denied % Oops... What's wrong... /tmp is as follow: % mount | grep tmp /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) % dumpfs /tmp | grep journal flags soft-updates+journal % And working scene: Windows 2: % chmod u+w /tmp/lockfile % ls -l /tmp/lockfile -rwsr-x--- 1 daichi wheel 0 10月 5 15:22 /tmp/lockfile % ./test_fcntl My pid: 43646 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=43490 has the lock % What's your umask and what are the permissions on /tmp? % ll / | grep tmp drwxrwxrwt 14 root wheel 1024 10月 5 17:19 tmp % umask 022 % rm -f test % touch test % ll | grep test -rw-r--r-- 1 daichi wheel 0 10月 5 17:52 test % The permissions look ok from my perspective, but the umask is different, so you might want to try my umask to make sure that your results match mine (and we need to check the requirements to determine whether or not the behavior for FreeBSD's umask syscall is correct): $ ls -la /tmp/ | head -n 2 total 462686 drwxrwxrwt 51 root wheel 11776 Oct 5 03:11 . $ umask 0022 The results are different on some users, even on the same user! (022 and 0022 shows the same results.) test user: $ rm -f /tmp/lockfile $ ./test_fcntl My pid: 63133 ^C $ ll /tmp/lockfile ---sr- 1 test wheel - 0 Oct 7 23:16 /tmp/lockfile* $ daichi: % rm -f /tmp/lockfile % ./test_fcntl My pid: 63140 ^C % ll /tmp/lockfile ---Sr-x--- 1 daichi wheel 0 10月 7 23:17 /tmp/lockfile % But above daichi's result was ---sr- as the same as test user. After some operation, it turns into returing ---Sr-x---. I didn't remember what operation did that. root: # rm -f /tmp/lockfile # ./test_fcntl My pid: 63147 ^C # ls -l /tmp/lockfile --wSr-S--- 1 root wheel 0 Oct 7 23:20 /tmp/lockfile # It is mystery. Where and how is /tmp mounted (is it a real partition, what filesystem, etc)? UFS+SUJ+noatime real pertition. I checked atime version, and got the same result. BTW, when I change my umask to match your's I don't get the same results you do on my home machine: Window 1: $ umask 022 $ ./test_fcntl My pid: 17353 Window 2: $ ./test_fcntl My pid: 17356 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=17353 has the lock $ ls -l /tmp/lockfile -rwSr- 1 gcooper wheel 0 Oct 5 07:49 /tmp/lockfile Just to note, the tests before were run on the RHEL 4.8 box with the following info, and the FreeBSD box with the following info: Red Hat Enterprise Linux AS release 4 (Nahant Update 8) Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r211767M: Sat Aug 28 00:28:45 PDT 2010 garrc...@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK amd64 The tests above were run on a FreeBSD box with the following info: FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: Thu Aug 19 22:50:36 PDT 2010 r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 On bayonetta /tmp is SUJ backed (probably should change that though), and on bioshock it's not SUJ backed. Thanks! -Garrett Still now, I couldn't find the cause of this issue, but it's ok by code following, and program should set permission at creating time I guess. fd = open(/tmp/lockfile, O_CREAT|O_WRONLY,0600); ___ 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 ___ 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: fcntl always fails to delete lock file, and PID is always -6464
On Oct 5, 2010, at 7:09 PM, Garrett Cooper wrote: On Tue, Oct 5, 2010 at 8:58 AM, Garrett Cooper gcoo...@freebsd.org wrote: On Tue, Oct 5, 2010 at 7:52 AM, Garrett Cooper gcoo...@freebsd.org wrote: On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO dai...@ongs.co.jp wrote: On Tue, 5 Oct 2010 01:23:02 -0700 Garrett Cooper gcoo...@freebsd.org wrote: 2010/10/4 Daichi GOTO dai...@ongs.co.jp: Thanks nice test tool :) And at last I got it excepting one mystery! On Mon, 4 Oct 2010 20:17:08 -0700 Garrett Cooper gcoo...@freebsd.org wrote: Following through the same process on FreeBSD... Window 1: $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory $ ./test_fcntl Window 2: $ ls -l /tmp/lockfile -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile $ ./test_fcntl test_fcntl: fcntl: Resource temporarily unavailable Just my mystery is as follow: Windows 1: % ./test_fcntl My pid: 43490 Windows 2: % ls -l /tmp/lockfile -r-sr-x--- 1 daichi wheel 0 10月 5 15:02 /tmp/lockfile--- is it weird, isn't it? % ./test_fcntl test_fcntl: open: Permission denied % Oops... What's wrong... /tmp is as follow: % mount | grep tmp /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) % dumpfs /tmp | grep journal flags soft-updates+journal % And working scene: Windows 2: % chmod u+w /tmp/lockfile % ls -l /tmp/lockfile -rwsr-x--- 1 daichi wheel 0 10月 5 15:22 /tmp/lockfile % ./test_fcntl My pid: 43646 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=43490 has the lock % What's your umask and what are the permissions on /tmp? % ll / | grep tmp drwxrwxrwt 14 root wheel 1024 10月 5 17:19 tmp % umask 022 % rm -f test % touch test % ll | grep test -rw-r--r-- 1 daichi wheel 0 10月 5 17:52 test % The permissions look ok from my perspective, but the umask is different, so you might want to try my umask to make sure that your results match mine (and we need to check the requirements to determine whether or not the behavior for FreeBSD's umask syscall is correct): $ ls -la /tmp/ | head -n 2 total 462686 drwxrwxrwt 51 root wheel 11776 Oct 5 03:11 . $ umask 0022 Where and how is /tmp mounted (is it a real partition, what filesystem, etc)? BTW, when I change my umask to match your's I don't get the same results you do on my home machine: Window 1: $ umask 022 $ ./test_fcntl My pid: 17353 Window 2: $ ./test_fcntl My pid: 17356 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=17353 has the lock $ ls -l /tmp/lockfile -rwSr- 1 gcooper wheel 0 Oct 5 07:49 /tmp/lockfile Just to note, the tests before were run on the RHEL 4.8 box with the following info, and the FreeBSD box with the following info: Red Hat Enterprise Linux AS release 4 (Nahant Update 8) Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r211767M: Sat Aug 28 00:28:45 PDT 2010 garrc...@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK amd64 The tests above were run on a FreeBSD box with the following info: FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: Thu Aug 19 22:50:36 PDT 2010 r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 On bayonetta /tmp is SUJ backed (probably should change that though), and on bioshock it's not SUJ backed. And while this might be a good mental exercise, I think we're missing the original point of your bug: You were getting ECONNREFUSED because a socket was in `use', even though all instances of mozc_server were dead (at least that's the case with me). So the question I guess that's worth asking is: Statement incorrect: socket wasn't in use. The logic needs to be rewritten to account for this case and setup the socket again if this occurs. It would be a good idea to do this if the file wasn't locked. Maybe behavior difference of fcntl when called with F_SETLN or F_GETLN you found is the answer of this issue. I'll try to check it out. Thanks! And I'll try to treat correct l_pid when called with F_SETLN. I guess this change will be benefits for other applications that use fcntl(2) like mozc_server does. 1. What process/application does it need to establish a Unix style socket with? 2. Why isn't that socket being cleaned up by the OS at exit? Thanks! -Garrett ___ 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 ___ 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: fcntl always fails to delete lock file, and PID is always -6464
Thanks nice test tool :) And at last I got it excepting one mystery! On Mon, 4 Oct 2010 20:17:08 -0700 Garrett Cooper gcoo...@freebsd.org wrote: Following through the same process on FreeBSD... Window 1: $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory $ ./test_fcntl Window 2: $ ls -l /tmp/lockfile -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile $ ./test_fcntl test_fcntl: fcntl: Resource temporarily unavailable Just my mystery is as follow: Windows 1: % ./test_fcntl My pid: 43490 Windows 2: % ls -l /tmp/lockfile -r-sr-x--- 1 daichi wheel 0 10月 5 15:02 /tmp/lockfile--- is it weird, isn't it? % ./test_fcntl test_fcntl: open: Permission denied % Oops... What's wrong... /tmp is as follow: % mount | grep tmp /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) % dumpfs /tmp | grep journal flags soft-updates+journal % And working scene: Windows 2: % chmod u+w /tmp/lockfile % ls -l /tmp/lockfile -rwsr-x--- 1 daichi wheel 0 10月 5 15:22 /tmp/lockfile % ./test_fcntl My pid: 43646 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=43490 has the lock % -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto ___ 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: fcntl always fails to delete lock file, and PID is always -6464
Next step discussion engaged from this research I guess. Should we do change FreeBSD's fcntl(2) to return correct l_pid when called with F_SETLK? Or keep current behavior?? I want to hear other developers ideas and suggetions. On Mon, 4 Oct 2010 20:17:08 -0700 Garrett Cooper gcoo...@freebsd.org wrote: test_fcntl: fcntl: Resource temporarily unavailable PID=1 has the lock Huh...? init has the file locked...? WTF?! So assuming Occam's Razor, I did a bit more reading and it turns out that l_pid is only populated when you call with F_GETLK: negative, l_start means end edge of the region. The l_pid and l_sysid fields are only used with F_GETLK to return the process ID of the process holding a blocking lock and the system ID of the system that owns that process. Locks created by the local system will have a system ID of zero. After a successful F_GETLK request, the value of l_whence is SEEK_SET. Thus, after fixing the test app I'm getting a sensical value: -- Daichi GOTO 81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto ___ 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: fcntl always fails to delete lock file, and PID is always -6464
On Tue, 5 Oct 2010 01:23:02 -0700 Garrett Cooper gcoo...@freebsd.org wrote: 2010/10/4 Daichi GOTO dai...@ongs.co.jp: Thanks nice test tool :) And at last I got it excepting one mystery! On Mon, 4 Oct 2010 20:17:08 -0700 Garrett Cooper gcoo...@freebsd.org wrote: Following through the same process on FreeBSD... Window 1: $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory $ ./test_fcntl Window 2: $ ls -l /tmp/lockfile -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile $ ./test_fcntl test_fcntl: fcntl: Resource temporarily unavailable Just my mystery is as follow: Windows 1: % ./test_fcntl My pid: 43490 Windows 2: % ls -l /tmp/lockfile -r-sr-x--- 1 daichi wheel 0 10月 5 15:02 /tmp/lockfile --- is it weird, isn't it? % ./test_fcntl test_fcntl: open: Permission denied % Oops... What's wrong... /tmp is as follow: % mount | grep tmp /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) % dumpfs /tmp | grep journal flags soft-updates+journal % And working scene: Windows 2: % chmod u+w /tmp/lockfile % ls -l /tmp/lockfile -rwsr-x--- 1 daichi wheel 0 10月 5 15:22 /tmp/lockfile % ./test_fcntl My pid: 43646 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=43490 has the lock % What's your umask and what are the permissions on /tmp? % ll / | grep tmp drwxrwxrwt 14 root wheel 1024 10月 5 17:19 tmp % umask 022 % rm -f test % touch test % ll | grep test -rw-r--r-- 1 daichi wheel 0 10月 5 17:52 test % ___ 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: fcntl always fails to delete lock file, and PID is always -6464
On Sun, 3 Oct 2010 22:05:12 -0700
Garrett Cooper gcoo...@freebsd.org wrote:
On Sun, Oct 3, 2010 at 8:37 PM, Daichi GOTO dai...@ongs.co.jp wrote:
It looks very strange. fcntl() always fails to delete lock file
and command.l_pid is always -6464. This issue is disclosed in
porting Google's Japanese input system called mozc.
details follow:
http://code.google.com/p/mozc/issues/detail?id=40
% uname -a
FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r213257:
Thu Sep 30 10:30:06 JST 2010
r...@parancell.ongs.co.jp:/usr/obj/usr/src/sys/PARANCELL amd64
%
My home directory on NFS server. Does anyone have any ideas?
I see some bad assumptions in the code:
const int result = ::fcntl(*fd, F_SETLK, command);
if (-1 == result) { // failed
::close(*fd);
LOG(WARNING) already locked;
return false; // another server is already running
}
If the developer actually coded to POSIX expectations, he/she
would be checking for EACCES/EAGAIN; there are a myriad of other
It was EAGAIN, when I checked. And -6464 is very strange
It should be -1 when it fails with EGAIN according to FreeBSD
fcntl(2) manual.
Repeat is easy:
# cd /usr/ports/japanese/mozc-server/
# rm files/patch-server_mozc_server.cc
# make WITH_DEBUG_CODE=yes install clean
% mozc_server
^C-- in this timing, lock files should be deleted, but not working.
% mozc_server -- so server will not run and finish soon
%
% cat ~/.mozc/mozc_server.log
issues that might be occurring with the software, as per my copy of
SUSv4 (see the ERRORS section of fcntl). I would print out the
strerror for that case.
Providing a backtrace of the application's execution and the
architecture and what version of FreeBSD you're using would be
helpful.
Thanks,
-Garrett
--
Daichi GOTO
CEO | ONGS Inc.
81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp
LinkedIn: http://linkedin.com/in/daichigoto
___
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: fcntl always fails to delete lock file, and PID is always -6464
On Mon, 4 Oct 2010 07:19:45 -0700 Garrett Cooper gcoo...@freebsd.org wrote: issues that might be occurring with the software, as per my copy of SUSv4 (see the ERRORS section of fcntl). I would print out the strerror for that case. Providing a backtrace of the application's execution and the architecture and what version of FreeBSD you're using would be helpful. I'm not even getting that far. Logs attached from both runs (WITH_DEBUG_CODE and WITHOUT_DEBUG_CODE). Yeah, it looks like the same situation. 1) mozc_server was killed lock file remains (even though it should be removed) 2) mozc_server try to boot 1. check lock file there 2. there is lock file, so cannot get lock file via fcntl 3. lock file means there is another mozc_server running, so mozc_server will stop boot and finish The cause of problem is that kernel does not remove lock file after mozc_server killed. Mozc developer explained me that fcntl will remove lock file after that process killed. But it looks like fnctl() does not remove lock file itself. According to FreeBSD fcntl(2) manual: All locks associated with a file for a given process are removed when the process terminates. No explanation lock file removing. Does FreeBSD fnctl(2) not remove lock file after process killed? Apparently from Mozc developer, Linux kernel removes lock files after process killed. $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: Thu Aug 19 22:50:36 PDT 2010 r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 I completely blasted past the part of your reply above where you said your home directory is served up via NFS. It might be a problem if you don't have lockd running (/etc/rc.d/lockd onestatus ? It isn't enabled by default, and definitely isn't on on my machine) or the mount isn't setup with lockd on the client side (nolockd will do this on the initial mount, according to the manpage). There might be `dragons' in the nfsd code that fail to do locking properly, but I think that Rick (rmacklem@) or someone else on the list might be better at answering whether or not things work from an NFS perspective. server side: FreeBSD 7.3-PRERELEASE #0: Mon Mar 1 15:10:07 JST 2010 i386 rc.conf nfs_server_enable=YES mountd_enable=YES nfs_reserved_port_only=YES rpc_lockd_enable=YES rpc_statd_enable=YES client side: FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010 amd64 rc.conf: nfs_client_enable=YES nfs_reserved_port_only=YES rpc_lockd_enable=YES rpc_statd_enable=YES I'd definitely divulge which version of NFS you're using as well as what your NFS server and client are running if enabling lockd both client and server side doesn't solve your problems right away. Cheers, -Garrett I have tested with ZFS because I was doubting NFS working well, but result was the same. (I didn't test with UFS.) Thanks truss output! ___ 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
fcntl always fails to delete lock file, and PID is always -6464
It looks very strange. fcntl() always fails to delete lock file and command.l_pid is always -6464. This issue is disclosed in porting Google's Japanese input system called mozc. details follow: http://code.google.com/p/mozc/issues/detail?id=40 % uname -a FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010 r...@parancell.ongs.co.jp:/usr/obj/usr/src/sys/PARANCELL amd64 % My home directory on NFS server. Does anyone have any ideas? -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto ___ 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
unionfs a little improvement
Hi Ed and unionfs fan gyus.
Ed pointed out a contradict behavior between current
unionfs implementation and its manual, and sent me a
patch.
Thanks Ed ;)
Index: sys/fs/unionfs/union_vfsops.c
===
--- sys/fs/unionfs/union_vfsops.c (revision 211093)
+++ sys/fs/unionfs/union_vfsops.c (working copy)
@@ -89,7 +89,6 @@
u_short ufile;
unionfs_copymode copymode;
unionfs_whitemode whitemode;
- struct componentname fakecn;
struct nameidata nd, *ndp;
struct vattrva;
@@ -280,26 +279,6 @@
mp-mnt_flag |= ump-um_uppervp-v_mount-mnt_flag MNT_RDONLY;
/*
-* Check whiteout
-*/
- if ((mp-mnt_flag MNT_RDONLY) == 0) {
- memset(fakecn, 0, sizeof(fakecn));
- fakecn.cn_nameiop = LOOKUP;
- fakecn.cn_thread = td;
- error = VOP_WHITEOUT(ump-um_uppervp, fakecn, LOOKUP);
- if (error) {
- if (below) {
- VOP_UNLOCK(ump-um_uppervp, 0);
- vrele(upperrootvp);
- } else
- vput(ump-um_uppervp);
- free(ump, M_UNIONFSMNT);
- mp-mnt_data = NULL;
- return (error);
- }
- }
-
- /*
* Unlock the node
*/
VOP_UNLOCK(ump-um_uppervp, 0);
Ed's message here:
Just for fun I was hacking on a writable bootcd, using unionfs and
tmpfs. I noticed tmpfs doesn't support whiteouts (yet). This prevents
unionfs from mounting tmpfs on top. I do want to be able to use tmpfs,
even if it means we can't get any whiteouts.
The manpage says the following:
Without whiteout support from the file system backing the upper layer,
there is no way that delete and rename operations on lower layer
objects
can be done. EROFS is returned for this kind of operations along with
any others which would make modifications to the lower layer, such as
chmod(1).
This seems to contradict the current behaviour, which is to deny the
mount altogether. The attached patch makes it work, but instead of
EROFS, it now returns EOPNOTSUPP, as generated by VOP_WHITEOUT().
It looks like reasonable and patch is simple and effective I guess.
If you unionfs guys or fs guys have some ideas around this patch,
please teach me.
After some tests and a couple of weeks after, I'll commit ed's patch
if there is no objections.
--
Daichi GOTO
81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp
LinkedIn: http://linkedin.com/in/daichigoto
___
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
unionfs a little improvement
Hi Ed and unionfs fan gyus.
Ed pointed out a contradict behavior between current
unionfs implementation and its manual, and sent me a
patch.
Thanks Ed ;)
Index: sys/fs/unionfs/union_vfsops.c
===
--- sys/fs/unionfs/union_vfsops.c (revision 211093)
+++ sys/fs/unionfs/union_vfsops.c (working copy)
@@ -89,7 +89,6 @@
u_short ufile;
unionfs_copymode copymode;
unionfs_whitemode whitemode;
- struct componentname fakecn;
struct nameidata nd, *ndp;
struct vattrva;
@@ -280,26 +279,6 @@
mp-mnt_flag |= ump-um_uppervp-v_mount-mnt_flag MNT_RDONLY;
/*
-* Check whiteout
-*/
- if ((mp-mnt_flag MNT_RDONLY) == 0) {
- memset(fakecn, 0, sizeof(fakecn));
- fakecn.cn_nameiop = LOOKUP;
- fakecn.cn_thread = td;
- error = VOP_WHITEOUT(ump-um_uppervp, fakecn, LOOKUP);
- if (error) {
- if (below) {
- VOP_UNLOCK(ump-um_uppervp, 0);
- vrele(upperrootvp);
- } else
- vput(ump-um_uppervp);
- free(ump, M_UNIONFSMNT);
- mp-mnt_data = NULL;
- return (error);
- }
- }
-
- /*
* Unlock the node
*/
VOP_UNLOCK(ump-um_uppervp, 0);
Ed's message here:
Just for fun I was hacking on a writable bootcd, using unionfs and
tmpfs. I noticed tmpfs doesn't support whiteouts (yet). This prevents
unionfs from mounting tmpfs on top. I do want to be able to use tmpfs,
even if it means we can't get any whiteouts.
The manpage says the following:
Without whiteout support from the file system backing the upper layer,
there is no way that delete and rename operations on lower layer
objects
can be done. EROFS is returned for this kind of operations along with
any others which would make modifications to the lower layer, such as
chmod(1).
This seems to contradict the current behaviour, which is to deny the
mount altogether. The attached patch makes it work, but instead of
EROFS, it now returns EOPNOTSUPP, as generated by VOP_WHITEOUT().
It looks like reasonable and patch is simple and effective I guess.
If you unionfs guys or fs guys have some ideas around this patch,
please teach me.
After some tests and a couple of weeks after, I'll commit ed's patch
if there is no objections.
--
Daichi GOTO
CEO | ONGS Inc.
81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp
LinkedIn: http://linkedin.com/in/daichigoto
___
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
