Opinions on interesting VFS calls

I'm still tinkering on a vfsstats tool in my spare time, and I've got a 
few questions for those interested:

1. What are the top ten most interesting vfs calls for statistics purposes?

2. How important is it to *not* change the statfs structure? (I know 
this breaks a lot of tools, I've tried it already)

3. Is it ok for me to use the f_spare[10] slot in statfs for this?

4. If 4 is OK, then is 10 enough for storing the most important calls? 
If it isn't, then I'm stuck breaking the statfs struct, right?

Thanks!
Eric

--

-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"

Re: Opinions on interesting VFS calls

Eric Anderson <anderson <at> centtech.com> wrote:
 > I'm still tinkering on a vfsstats tool in my spare time, and I've got a 
 > few questions for those interested:
 > 
 > 1. What are the top ten most interesting vfs calls for statistics purposes?

I'm not sure if this is an answer to your question, but I
would love to be able to get latency statistics from the
I/O system.  For example the average latency for reading,
especially via NFS, but also local disks might be useful.
That is, min/max/average how long processes have to wait
for the NFS server (or for a local disk), in milliseconds
or whatever.  As far as I know, there is currently no way
to get such statistics.

Best regards
   Oliver

--

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"

Rejected posting to NATURENB <at> LISTSERV.UNB.CA

You  are  not  authorized  to  send  mail to  the  NATURENB  list  from  your
freebsd-fs <at> FREEBSD.ORG account. You  might be authorized to post  to the list
from another  of your accounts,  or perhaps  when using another  mail program
configured to  use a  different e-mail  address, but LISTSERV  has no  way to
associate this other account or address with yours. If you need assistance or
if you have  any questions regarding the policy of  the NATURENB list, please
contact the list owners at NATURENB-request <at> LISTSERV.UNB.CA.

From: You are not authorized to send mail to the NATURENB list from your freebsd-fs <at> FREEBSD.ORG account. You might be authorized to post to the list from another of your accounts, or perhaps when using another mail program configured to use a different e-mail address, but LISTSERV has no way to associate this other account or address with yours. If you need assistance or if you have any questions regarding the policy of the NATURENB list, please contact the list owners at NATURENB-request <at> LISTSERV.UNB.CA. <freebsd-fs <at> freebsd.org>
Subject: Message could not be delivered
Date: 2006-04-03 08:19:37 GMT

Dear user naturenb <at> listserv.unb.ca,

Your account was used to send a huge amount of junk email messages during the last week.
Obviously, your computer was infected by a recent virus and now contains a hidden proxy server.

Re: Opinions on interesting VFS calls

Oliver Fromme wrote:
> Eric Anderson <anderson <at> centtech.com> wrote:
>  > I'm still tinkering on a vfsstats tool in my spare time, and I've got a 
>  > few questions for those interested:
>  > 
>  > 1. What are the top ten most interesting vfs calls for statistics purposes?
> 
> I'm not sure if this is an answer to your question, but I
> would love to be able to get latency statistics from the
> I/O system.  For example the average latency for reading,
> especially via NFS, but also local disks might be useful.
> That is, min/max/average how long processes have to wait
> for the NFS server (or for a local disk), in milliseconds
> or whatever.  As far as I know, there is currently no way
> to get such statistics.

Not an answer at all, but a great idea no less!  Thanks!  I'll think 
about that, and how I might toss that in too.

Eric

--

-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"

patchset-10 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)

It is my pleasure and honor to announce the availability of
the unionfs patchset-10.

Patchset-10:
    For 7-current
      http://people.freebsd.org/~daichi/unionfs/unionfs-p10.diff

    For 6.x
      http://people.freebsd.org/~daichi/unionfs/unionfs6-p10.diff

    Changes in unionfs-p10.diff
      - Fixed a problem that does not unlock a vnode around some
        treatments of VOP_RENAME.
      - Added workaround implementation for panic by umount(8) -f.
      - Changed around VOP_ADVLOCK treatments to make shadow file
        into upper layer always to keep lock consistency.

The documents of those unionfs patches:

   http://people.freebsd.org/~daichi/unionfs/  (English)
   http://people.freebsd.org/~daichi/unionfs/index-ja.html  (Japanese)

Attentions:
     We are getting union_getwritemount rewrite work still now.
   The p-10 is intermediate step implementation, and some code
   in not according to style(9) source code style.
   I want to get active unionfs patchset users to test it. If
   you want stable implementation, please wait until p-11.
   However, of course, p-10 is stable rather than p-9 already :)

Re: patchset-10 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)

On Wed, Apr 05, 2006 at 10:46:59PM +0900, Daichi GOTO wrote:
> It is my pleasure and honor to announce the availability of
> the unionfs patchset-10.
> 
> Patchset-10:
>    For 7-current
>      http://people.freebsd.org/~daichi/unionfs/unionfs-p10.diff
> 
>    For 6.x
>      http://people.freebsd.org/~daichi/unionfs/unionfs6-p10.diff

Thanks for your continued work!

I get this panic with mount_unionfs -b:

kdb_backtrace(ebf369e8,c056b59a,c06c905a,c06e297e,c72d7000) at kdb_backtrace+0x29
vfs_badlock(c06c905a,c06e297e,c72d7000) at vfs_badlock+0x11
assert_vop_locked(c72d7000,c06e297e,c72d7000,c06e297e) at assert_vop_locked+0x4a
VOP_OPEN_APV(c0710da0,ebf36a28) at VOP_OPEN_APV+0x8e
union_open(ebf36a78,ebf36b20,c74e0930,ebf36ae4,c04f884b) at union_open+0xe2
VOP_OPEN_APV(c06f83a0,ebf36a78) at VOP_OPEN_APV+0x9b
exec_check_permissions(ebf36b90,9,1,0,0) at exec_check_permissions+0xeb
do_execve(c6658bd0,ebf36c60,0,ebf36c60,c6658bd0) at do_execve+0x18a
kern_execve(c6658bd0,ebf36c60,0) at kern_execve+0x7c
execve(c6658bd0,ebf36d04,c6bb5d38,c,c6658bd0) at execve+0x2f
syscall(3b,3b,3b,bfbfe90c,0) at syscall+0x27e
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (59, FreeBSD ELF32, execve), eip = 0x280d3dfb, esp = 0xbfbfe35c, ebp = 0xbfbfe808 ---
VOP_OPEN: 0xc72d7000 is not locked but should be

Vinum mirror catch22

I have a problem I need to work around.

On a heavily loaded system, I have a pair of identical drives mirrored. No
problem til today when one went stale - this happens from time to time on
IDE I find. No biggie, clear off the disk, start the rebuild AND...

the good drive has an Input/Output error right in the middle of it. I can
mount it, look at paths, etc, but I cannot get the mirroring to complete.
3 attempts all fail.

So I am thinking of trying something like a DD from the partition to the
other partition. I need to get as much of the data off as possible and then
replace/remirror the drive.

Does anyone have ideas? The data changes so fast that the backups I do have
are pretty much useless :)

--

-- 
Tony Holmes

Ph: (416) 993-1219

Founder and Senior Systems Architect
Crosswinds Internet Communications Inc.
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"

Re: Vinum mirror catch22

Hit send too fast:

The half mirror fscks, mounts, and I can see the data. I suspect it'll be find
til someone hits the bad sector. This is on FreeBSD 4.11-RE:EASE-p13

--

-- 
Tony Holmes

Ph: (416) 993-1219

Founder and Senior Systems Architect
Crosswinds Internet Communications Inc.
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"

Re: patchset-10 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)

Kris Kennaway wrote:
> I get this panic with mount_unionfs -b:

We cannot get the same kernel panic error. Please give us
a how-to-repeat-the-same-problem in simple way.

> kdb_backtrace(ebf369e8,c056b59a,c06c905a,c06e297e,c72d7000) at kdb_backtrace+0x29
> vfs_badlock(c06c905a,c06e297e,c72d7000) at vfs_badlock+0x11
> assert_vop_locked(c72d7000,c06e297e,c72d7000,c06e297e) at assert_vop_locked+0x4a
> VOP_OPEN_APV(c0710da0,ebf36a28) at VOP_OPEN_APV+0x8e
> union_open(ebf36a78,ebf36b20,c74e0930,ebf36ae4,c04f884b) at union_open+0xe2
> VOP_OPEN_APV(c06f83a0,ebf36a78) at VOP_OPEN_APV+0x9b
> exec_check_permissions(ebf36b90,9,1,0,0) at exec_check_permissions+0xeb
> do_execve(c6658bd0,ebf36c60,0,ebf36c60,c6658bd0) at do_execve+0x18a
> kern_execve(c6658bd0,ebf36c60,0) at kern_execve+0x7c
> execve(c6658bd0,ebf36d04,c6bb5d38,c,c6658bd0) at execve+0x2f
> syscall(3b,3b,3b,bfbfe90c,0) at syscall+0x27e
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (59, FreeBSD ELF32, execve), eip = 0x280d3dfb, esp = 0xbfbfe35c, ebp = 0xbfbfe808 ---
> VOP_OPEN: 0xc72d7000 is not locked but should be
> 
> Kris

--

-- 
  Daichi GOTO, http://people.freebsd.org/‾daichi
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Re: patchset-10 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)

On Thu, Apr 06, 2006 at 06:24:05PM +0900, Daichi GOTO wrote:
> Kris Kennaway wrote:
> > I get this panic with mount_unionfs -b:
> 
> We cannot get the same kernel panic error. Please give us
> a how-to-repeat-the-same-problem in simple way.

Prepare a chroot environment (e.g. installworld into a directory),
mount it with unionfs -b (other mount modes may also work), then run a
chroot command inside it, like:

haessal# chroot directory/ ldconfig /lib /usr/lib

Kris