Re: "df /" output missing "Filesystem" after r351187 -> r351211
On August 19, 2019 7:15:53 AM PDT, Warner Losh wrote: >On Mon, Aug 19, 2019 at 8:14 AM Mateusz Guzik >wrote: > >> On 8/19/19, David Wolfskill wrote: >> > "df" (without the mountpoint specification) is normal, but >specifying >> > the mountpoint appears to cause a large number of "space" >characters >> > to be emitted after "Filesystem" in the heading, and the actual >> > "filesystem" data to be elided. >> > >> >> Should be fixed with r351215 >> >> https://svnweb.freebsd.org/base?view=revision=351215 > > >Thanks for the quick fix... > >Warner >___ >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" Yes. I replied privately, this is fixed now. Thank you for the quick fix. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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"
Re: "df /" output missing "Filesystem" after r351187 -> r351211
On Mon, Aug 19, 2019 at 8:14 AM Mateusz Guzik wrote: > On 8/19/19, David Wolfskill wrote: > > "df" (without the mountpoint specification) is normal, but specifying > > the mountpoint appears to cause a large number of "space" characters > > to be emitted after "Filesystem" in the heading, and the actual > > "filesystem" data to be elided. > > > > Should be fixed with r351215 > > https://svnweb.freebsd.org/base?view=revision=351215 Thanks for the quick fix... Warner ___ 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"
Re: "df /" output missing "Filesystem" after r351187 -> r351211
On 8/19/19, David Wolfskill wrote: > "df" (without the mountpoint specification) is normal, but specifying > the mountpoint appears to cause a large number of "space" characters > to be emitted after "Filesystem" in the heading, and the actual > "filesystem" data to be elided. > Should be fixed with r351215 https://svnweb.freebsd.org/base?view=revision=351215 -- Mateusz Guzik ___ 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"
Re: "df /" output missing "Filesystem" after r351187 -> r351211
On Mon, Aug 19, 2019 at 5:39 AM David Wolfskill wrote: > > "df" (without the mountpoint specification) is normal, but specifying > the mountpoint appears to cause a large number of "space" characters > to be emitted after "Filesystem" in the heading, and the actual > "filesystem" data to be elided. > > E.g.: > > freebeast(13.0-C)[1] uname -aUK > FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #646 > r351211M/351211: Mon Aug 19 04:04:14 PDT 2019 > r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 1300040 1300040 > freebeast(13.0-C)[2] df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ada0s4a 3044988 583648 221774421%/ > devfs11 0 100%/dev > tmpfs 83886088 8388600 0%/tmp > /dev/ada0s1a 3044988 642532 215886023%/S1 > /dev/ada0s1d 9135164 4464464 393988853%/S1/usr > /dev/ada0s2a 3044988 642532 215886023%/S2 > /dev/ada0s2d 9135164 4456680 394767253%/S2/usr > /dev/ada0s3a 3044988 588984 221240821%/S3 > /dev/ada0s3d 9135164 4691128 371322456%/S3/usr > /dev/ada0s4d 9135164 4840820 356353258%/usr > /dev/ada0s4e 64995324 44512284 1528341674%/common > /dev/ada0s4g 40614492 797560 36567776 2%/local > /dev/ada0s4f 5061628 104292 4552408 2%/var > /dev/ada0s4h 129990748 10965504 108625988 9%/repo > map -hosts 00 0 100%/net > freebeast(13.0-C)[3] df / > Filesystem > > > > > > > > > > > > 1K-blocks Used Avail Capacity Mounted on >3044988 583648 221774421% > freebeast(13.0-C)[4] df / | hd > 46 69 6c 65 73 79 73 74 65 6d 20 20 20 20 20 20 |Filesystem | > 0010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 || > * > 08d0 20 20 20 20 20 20 20 20 20 31 4b 2d 62 6c 6f 63 | 1K-bloc| > 08e0 6b 73 20 20 20 55 73 65 64 20 20 20 41 76 61 69 |ks Used Avai| > 08f0 6c 20 43 61 70 61 63 69 74 79 20 20 4d 6f 75 6e |l Capacity Moun| > 0900 74 65 64 20 6f 6e 0a 20 20 20 33 30 34 34 39 38 |ted on. 304498| > 0910 38 20 35 38 33 36 34 38 20 32 32 31 37 37 34 34 |8 583648 2217744| > 0920 20 20 20 20 32 31 25 20 20 20 20 0a |21%.| > 092c > freebeast(13.0-C)[5] > > As time permits, I'll try to untangle what's going on, but I confess to > a lack of familiarity with the code, so it probably won't be as soone as > I would prefer. And the behavior could cause scripts to behave ... oddly. > > Peace, > david > -- > David H. Wolfskill
Re: df: negative overflow?
* Melvyn Sopacua [EMAIL PROTECTED] [031126 13:23]: /dev/ad0s2e ? 989M ? 947M -36.4M ? 104% ? ?/var This is normal. Each filesystem has a chunk of reserved space for root-only, for disaster recovery and such. Your /var filesystem is full, and has begun overflowing into that reserved space by 36.4MB. Essentially, there is no free space left in the file system, and you must get rid of 36.4MB of data before you can begin to get any free space. --Mike pgp0.pgp Description: PGP signature
Re: df: negative overflow?
On Wednesday 26 November 2003 19:52, Michael Edenfield wrote: * Melvyn Sopacua [EMAIL PROTECTED] [031126 13:23]: /dev/ad0s2e ? 989M ? 947M -36.4M ? 104% ? ?/var This is normal. Each filesystem has a chunk of reserved space for root-only, Yes, sorry I wasn't too clear (I thought the bug would stand out). But here's the really important line: /dev/ad0s2e 989 946 36028797018963931 104% /var ^ Looks like an integer overflow of some kind. --Mike -- Melvyn pgp0.pgp Description: signature
Re: df problems ?
Is there any way of obtaining a list of superblocks on a fs, apart from making a note of the list newfs produces? dumpfs(8) There is, as I've just discovered, a -N option to newfs, which displays what it is going to do but doesn't write to the disk. One slip of the typing fingers and you're sunk. It seems that superblocks are always in the same place, but there are more on larger disks. This seems to apply for all the disks I've looked at. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df problems ?
This is all very true for 4.7, but what about earlier versions. I compiled fsck using 4.7 srcs, includes and hierarchy with 4.0 libraries and tools, so that I could have an fsck I could use with my 4.0 CDROM (the latest one I have, unfortunately) to repair any changes made by my CURRENT system. It does compile with the same errors you get on a true 4.7 system about unsigned/signed comparisons. It even works as a program, but it does not repair the filesystem properly to be compatible with 4.0. You get an instant panic when going multi-user. This is a real nuisance as it blows my recovery strategy should I ever need it. If someone could figure out how to fix this I would be grateful until the time I get my hands on a 5.0 CDROM I tried it again today and it worked (fsck'ing CURRENT drives with my fsck version 4.7 compiled for 4.0 ). I don't know why it failed yesterday. Is there any way of obtaining a list of superblocks on a fs, apart from making a note of the list newfs produces? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df problems ?
On Sat, 26 Oct 2002, Dave Evans wrote: This is all very true for 4.7, but what about earlier versions. I compiled fsck using 4.7 srcs, includes and hierarchy with 4.0 libraries and tools, so that I could have an fsck I could use with my 4.0 CDROM (the latest one I have, unfortunately) to repair any changes made by my CURRENT system. It does compile with the same errors you get on a true 4.7 system about unsigned/signed comparisons. It even works as a program, but it does not repair the filesystem properly to be compatible with 4.0. You get an instant panic when going multi-user. This is a real nuisance as it blows my recovery strategy should I ever need it. If someone could figure out how to fix this I would be grateful until the time I get my hands on a 5.0 CDROM I tried it again today and it worked (fsck'ing CURRENT drives with my fsck version 4.7 compiled for 4.0 ). I don't know why it failed yesterday. Is there any way of obtaining a list of superblocks on a fs, apart from making a note of the list newfs produces? dumpfs(8) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df problems ?
In article [EMAIL PROTECTED] you write: Alexey Zelkin wrote: Folks, I have dual boot machine with -STABLE and -CURRENT (both have own boot slices and few slices are shared between them.) I don't know all the details, but -CURRENT recently changed the way information is recorded in the superblock. The first copy of the superblock will be different between -CURRENT and -STABLE. Any partitions that are shared between -STABLE and -CURRENT must be fsck'd before use on the opposite system. The fsck was changed in -STABLE to look for the difference and correct it without getting confused. This is all very true for 4.7, but what about earlier versions. I compiled fsck using 4.7 srcs, includes and hierarchy with 4.0 libraries and tools, so that I could have an fsck I could use with my 4.0 CDROM (the latest one I have, unfortunately) to repair any changes made by my CURRENT system. It does compile with the same errors you get on a true 4.7 system about unsigned/signed comparisons. It even works as a program, but it does not repair the filesystem properly to be compatible with 4.0. You get an instant panic when going multi-user. This is a real nuisance as it blows my recovery strategy should I ever need it. If someone could figure out how to fix this I would be grateful until the time I get my hands on a 5.0 CDROM The tape format for dump/restore has been changed as well between CURRENT-Jan 2001 and CURRENT-October 2002. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df
On 05/18/02 17:41, Ian Dowse wrote: In message [EMAIL PROTECTED], Terry Lambert writes: I think the reason for the if is to keep the df from hanging indefinitely, particularly when you give it an explicit list. No, I believe the if (vfslist != NULL) code was there to reduce the maximum column widths to those necessary for an explicit list of filesystems rather than using the maximum widths for all filesystems. The regetmntinfo() call before the if has already performed any operations that could hang indefinitely, so it makes sense to unconditionally use these up-to-date results instead of the potentially stale list from getmntinfo(..., MNT_NOWAIT). Ian That exactly matches my understanding of the code, the test for vfslist != NULL was there only to prevent recalculating the field widths when they couldn't have changed. Except it turns out they could have changed for other reasons than a non-null vfslist. Terry, the issue of hanging (WAIT versus NOWAIT) is controlled by the -n (nflag) option, and by whether you've specifically named filesystems on the command line (indicating you're willing to wait for those filesystems). The vfslist stuff is related to the -t option (filter the list down to filesystems of a given type). There's no relationship between the vfslist and waiting or not. -- Ian (the other one) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df
Ian wrote: Terry, the issue of hanging (WAIT versus NOWAIT) is controlled by the -n (nflag) option, and by whether you've specifically named filesystems on the command line (indicating you're willing to wait for those filesystems). The vfslist stuff is related to the -t option (filter the list down to filesystems of a given type). There's no relationship between the vfslist and waiting or not. My if include !nflag , if you will remember. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df
In message [EMAIL PROTECTED], Ian writes: Actually, I now think a more-correct fix would be to have no if statement at all, and just always recalculate the field widths after calling the routine to re-get the stats. Yes, I agree. Committed, thanks! Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df
Ian Dowse wrote: In message [EMAIL PROTECTED], Ian writes: Actually, I now think a more-correct fix would be to have no if statement at all, and just always recalculate the field widths after calling the routine to re-get the stats. Yes, I agree. Committed, thanks! Ian agrees with Ian...? ...I know, different Ian's. 8-). I think the reason for the if is to keep the df from hanging indefinitely, particularly when you give it an explicit list. Doesn't removing the if break that? 8-) -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df
In message [EMAIL PROTECTED], Terry Lambert writes: I think the reason for the if is to keep the df from hanging indefinitely, particularly when you give it an explicit list. No, I believe the if (vfslist != NULL) code was there to reduce the maximum column widths to those necessary for an explicit list of filesystems rather than using the maximum widths for all filesystems. The regetmntinfo() call before the if has already performed any operations that could hang indefinitely, so it makes sense to unconditionally use these up-to-date results instead of the potentially stale list from getmntinfo(..., MNT_NOWAIT). Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df
Ian Dowse wrote: In message [EMAIL PROTECTED], Terry Lambert writes: I think the reason for the if is to keep the df from hanging indefinitely, particularly when you give it an explicit list. No, I believe the if (vfslist != NULL) code was there to reduce the maximum column widths to those necessary for an explicit list of filesystems rather than using the maximum widths for all filesystems. The regetmntinfo() call before the if has already performed any operations that could hang indefinitely, so it makes sense to unconditionally use these up-to-date results instead of the potentially stale list from getmntinfo(..., MNT_NOWAIT). Like ps, df is a snapshot. As such, staleness after a few tenths of a second is really irrelevent, since the information is never really the real and precise information. It's more important to be able to get information in a misbehaving system, without hanging your shell forever. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df
On 05/17/02 10:27, Riccardo Torrini wrote:
I manually mount nfs fs after a reboot (current - stable) and
if I do a df I got two different output. First time it get
garbled, all other times it is aligned. I'm alone?
I looked at the df code because I was intensely curious how this could
happen. It obtains the list of mounts using a NOWAIT flag, and NFS mount
info may not be available immediately so it doesn't get included in the
field width calculations. Then later it re-gets the list of mounts using a
WAIT flag (unless you used -n on the command line) so this time it has the
info from NFS filesystems, but it doesn't recalculate the field widths. The
following patch should fix it without breaking other behaviors, I belive.
-- Ian
--- df.c.origFri May 17 11:30:55 2002
+++ df.cFri May 17 11:31:39 2002
@@ -203,7 +203,7 @@
rv = 0;
if (!*argv) {
mntsize = regetmntinfo(mntbuf, mntsize, vfslist);
-if (vfslist != NULL) {
+if (!nflag) {
bzero(maxwidths, sizeof(maxwidths));
for (i = 0; i mntsize; i++)
update_maxwidths(maxwidths, mntbuf[i]);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: df
On 05/17/02 14:09, Terry Lambert wrote:
Ian wrote:
On 05/17/02 10:27, Riccardo Torrini wrote:
I manually mount nfs fs after a reboot (current - stable) and
if I do a df I got two different output. First time it get
garbled, all other times it is aligned. I'm alone?
I looked at the df code because I was intensely curious how this could
happen. It obtains the list of mounts using a NOWAIT flag, and NFS mount
info may not be available immediately so it doesn't get included in the
field width calculations. Then later it re-gets the list of mounts using a
WAIT flag (unless you used -n on the command line) so this time it has the
info from NFS filesystems, but it doesn't recalculate the field widths. The
following patch should fix it without breaking other behaviors, I belive.
I guess the real question is why the NOWAIT flag results in the
NFS FS's not being included, since the purpose of NOWAIT is to
keep it from hanging indefinitely, not to keep high latency FS's
out of consideration.
I leave troublesome questions like that to people who like mucking around in
kernel and filesystem internals. I was just looking for something that
could cause apparently-stateful behavior across runs of the program and
decided I'd found a candidate cause.
Also, one would expect that the FS's that failed NOWAIT would
have their details left out, and be marked as could cause hang
if examined.
-if (vfslist != NULL) {
+if (!nflag) {
Uh, think this wants to be:
+if (!nflag || vfslist != NULL) {
The reason is that an explicit list of FS's on the command line
still means look these up, come hell or high water, and hang, if
you have to.
vfslist != NULL means the stats array could have had some entries filtered
out of it. Only if nflag is false could the array have grown to have new
entries. Still, if the array got filtered, then potentially some fields
could be displayed narrower than the first-cut calcs set up, so your
suggestion is more-correct. (Naming filesystems on the command line leads
to a completely different path thru the code where this change doesn't come
into play.)
Actually, I now think a more-correct fix would be to have no if statement at
all, and just always recalculate the field widths after calling the routine
to re-get the stats. The if statement strikes me as a troublesome
micro-optimization that smears info about the internal state of the re-get
routine's behavior to another outside routine. All to save a couple
microseconds. (Consider that this whole problem happened because already
the code was assuming the re-get routine wouldn't have changed the stats
array if vfslist was NULL, which incorrectly reflects the behavior of the
re-get routine.)
If it's really important to save these cycles, the recalc of the field
widths should move closer to the point at which the raw data is
(re-)obtained. But then you start asking yourself questions like why does
it bother to get the list with a NOWAIT then later get the list again with a
WAIT instead of just getting it once using the method 'nflag' implies? and
before you know it you're rewriting half the code. :-)
-- Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: df -l broken
Joerg Wunsch wrote: Maxime Henrion [EMAIL PROTECTED] wrote: I looked at the code a bit more closely and you're entirely right. I think I figured out why my patch caused a core dump. Here is a more correct patch that should fix the problem without causing core dumps. Seems to work. mount(8) has still the problem though: Great, I'll file a PR for it. Thanks for the feedback ! uriah # mount -t local uriah # kldload nfs uriah # mount -t local uriah # mount -t nonfs /dev/da0a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/vinum/var on /var (ufs, local, soft-updates) /dev/vinum/usr on /usr (ufs, local, soft-updates) /dev/vinum/home on /home (ufs, local, soft-updates) /dev/vinum/home_cvs on /home/cvs (ufs, NFS exported, local, soft-updates) /dev/vinum/src on /usr/src (ufs, local, soft-updates) /dev/vinum/othersrc on /usr/othersrc (ufs, local, soft-updates) /dev/vinum/obj on /usr/obj (ufs, local, soft-updates) /dev/vinum/ports on /usr/ports (ufs, local, soft-updates) /dev/vinum/distfiles on /usr/ports/distfiles (ufs, NFS exported, local, soft-updates) /dev/vinum/news on /var/spool/news (ufs, local, soft-updates) /dev/vinum/tmp on /tmp (ufs, NFS exported, local, soft-updates) /dev/vinum/release on /usr/release (ufs, NFS exported, local, soft-updates) /dev/vinum/junk on /junk (ufs, local, soft-updates) procfs on /proc (procfs, local, read-only) I fail to see why should ``mount -t local'' work. I don't see anything related in the mount(8) manpage. To my knowledge, -t is only used when specifying a particular fs type (nfs, msdosfs, ...) optionally prepended with a ``no''. If you point me to the relevant documentation, I'll be happy to fix this bug too. Thanks, Maxime Henrion -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df -l broken
As Maxime Henrion wrote: Seems to work. mount(8) has still the problem though: Great, I'll file a PR for it. Thanks for the feedback ! I can commit it if you want. I fail to see why should ``mount -t local'' work. ISTR that it used to work, at least in the context of mount -a -t local. I can't seem to find any old system to verify this claim, however. So maybe it's merely wishful thinking instead of something that has actually once been there... -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df -l broken
In local.freebsd.current you write: On Mon, Nov 26, 2001 at 12:07:22AM +0100, Maxime Henrion wrote: If my patch is exact, then the bug should manifest itself only if there are no network filesystems mounted. Do you have any network fs mounted on your box ? No networked filesystems here, and no problems: They don't have to be mounted, just loaded. E.g. if nfs shows up with lsvfs, df -l will work, if not, it won't. (dunno about other network file systems). Thus: gw% lsvfs FilesystemRefs Flags - --- ufs 5 procfs 1 synthetic gw% df -l gw% gw% su -m Password: gw# kldload nfs gw# ^D gw% lsvfs FilesystemRefs Flags - --- ufs 5 procfs 1 synthetic nfs 0 network gw% df -l Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s1a25406345332 18840619%/ /dev/ad0s1g 34487716 1482012 30246688 5%/home /dev/ad0s1e 2032623 519974 135004028%/usr /dev/ad0s1f 2032623 2901 1867113 0%/var procfs 440 100%/proc /dev/vn0c 1300204 119616 0%/tmp (This is on -STABLE, BTW) $.02, /Mikko [341]nathan@bokonon:~% df -k Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/da0s1a 99191529933826358%/ devfs 110 100%/dev /dev/da0s1f 6450317 4945823 98846983%/usr /dev/da0s1e 99191 781683440 9%/var procfs 440 100%/proc [342]nathan@bokonon:~% df -l Filesystem 512-blocks UsedAvail Capacity Mounted on /dev/da0s1a 198382 1059867652658%/ devfs220 100%/dev /dev/da0s1f 12900634 9891646 197693883%/usr /dev/da0s1e 19838215632 166880 9%/var procfs 880 100%/proc [343]nathan@bokonon:~% uname -a FreeBSD bokonon.rtfm.net 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Sun Nov 4 23:28:25 EST 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SAN_LORENZO i386 [...] -- Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df -l broken
Mikko Tyolajarvi wrote: In local.freebsd.current you write: On Mon, Nov 26, 2001 at 12:07:22AM +0100, Maxime Henrion wrote: If my patch is exact, then the bug should manifest itself only if there are no network filesystems mounted. Do you have any network fs mounted on your box ? No networked filesystems here, and no problems: They don't have to be mounted, just loaded. E.g. if nfs shows up with lsvfs, df -l will work, if not, it won't. (dunno about other network file systems). [...] I looked at the code a bit more closely and you're entirely right. I think I figured out why my patch caused a core dump. Here is a more correct patch that should fix the problem without causing core dumps. --- df.c1 Aug 2001 02:09:09 - 1.32 +++ df.c30 Nov 2001 01:06:52 - @@ -561,7 +561,9 @@ *strptr = ','; free(listptr[i]); } - *(--strptr) = NULL; + if (i 0) + strptr--; + *strptr = NULL; free(listptr); return (str); I would be happy to get some feedback, especially from the person who got a core dump. :-) Thanks, Maxime Henrion -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df -l broken
On Fri, 30 Nov 2001, Maxime Henrion wrote: Mikko Tyolajarvi wrote: [...] They don't have to be mounted, just loaded. E.g. if nfs shows up with lsvfs, df -l will work, if not, it won't. (dunno about other network file systems). [...] I looked at the code a bit more closely and you're entirely right. I think I figured out why my patch caused a core dump. Here is a more correct patch that should fix the problem without causing core dumps. FWIW: Seems to solve the problem on -STABLE. Didn't try your earlier attempt, so I don't have any core dump experiences ;-) $.02, /Mikko Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df -l broken
Maxime Henrion [EMAIL PROTECTED] wrote: I looked at the code a bit more closely and you're entirely right. I think I figured out why my patch caused a core dump. Here is a more correct patch that should fix the problem without causing core dumps. Seems to work. mount(8) has still the problem though: uriah # mount -t local uriah # kldload nfs uriah # mount -t local uriah # mount -t nonfs /dev/da0a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/vinum/var on /var (ufs, local, soft-updates) /dev/vinum/usr on /usr (ufs, local, soft-updates) /dev/vinum/home on /home (ufs, local, soft-updates) /dev/vinum/home_cvs on /home/cvs (ufs, NFS exported, local, soft-updates) /dev/vinum/src on /usr/src (ufs, local, soft-updates) /dev/vinum/othersrc on /usr/othersrc (ufs, local, soft-updates) /dev/vinum/obj on /usr/obj (ufs, local, soft-updates) /dev/vinum/ports on /usr/ports (ufs, local, soft-updates) /dev/vinum/distfiles on /usr/ports/distfiles (ufs, NFS exported, local, soft-updates) /dev/vinum/news on /var/spool/news (ufs, local, soft-updates) /dev/vinum/tmp on /tmp (ufs, NFS exported, local, soft-updates) /dev/vinum/release on /usr/release (ufs, NFS exported, local, soft-updates) /dev/vinum/junk on /junk (ufs, local, soft-updates) procfs on /proc (procfs, local, read-only) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df -l broken
In my dual Pentium3/1GHz box: % uname -a FreeBSD mako.kobe1995.net 5.0-CURRENT-20010830-JPSNAP FreeBSD 5.0-CURRENT-20010830-JPSNAP #9: Sat Nov 3 17:05:25 JST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KOBE5SMP i386 % df -l Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/da0s1a127023572155964749%/ devfs 110 100%/dev /dev/da0s1e 3935347 112806 3507714 3%/usr /dev/da0s2a127023346898217330%/altroot procfs 440 100%/proc % In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: If my patch is exact, then the bug should manifest itself only if there are no network filesystems mounted. Do you have any network fs mounted on your box ? % df Filesystem1K-blocks UsedAvail Capacity Mounted on /dev/da0s1a 127023572155964749%/ devfs 110 100%/dev /dev/da0s1e 3935347 112806 3507714 3%/usr /dev/da0s2a 127023346898217330%/altroot procfs440 100%/proc ace:/home 2318686 1079119 105407351%/home ace:/var/mail 63567 6558417 0%/var/mail safa:/mnt 113956615 1048400860 100%/mnt safa:/usr/local 1016047 9605325551595%/usr/local safa:/usr/X11R6 1016047 9605325551595%/usr/X11R6 safa:/mnt/ftp/pub/obj 113956615 1048400860 100%/usr/obj -- mailto:[EMAIL PROTECTED] NAKAMURA Kazushi@KOBE http://kobe1995.net/~kaz/index-e.html - Break the hate chain. No more kill! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df -l broken
Paul van der Zwan wrote: I noticed the -l option of the df command is broken. It is supposed to print df for local filesystems but on my system it prints nothing at all. I had a quick look at the code , as far as I can tell it uses sysctl to figure out the mounted filesystems but thinks all of them are non-local and ignores them. Using sysctl -a I could not find any entries which looked vaguely like describing a mount.. Paul Could you please test the attached patch ? I did it in a hurry but it may fix the problem. It looks ok to me, just the local mounts show up.. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df -l broken
Date: Sun, 25 Nov 2001 22:41:01 +0100 From: Paul van der Zwan [EMAIL PROTECTED] I noticed the -l option of the df command is broken That differs from my experience: d141[1] df -l Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s3a158783939195216264%/ devfs 110 100%/dev /dev/ad0s1a158767652608080645%/S1 /dev/ad0s1e 1871095 1059572 66183662%/S1/usr /dev/ad0s2a158767 1039454212171%/S2 /dev/ad0s2e 1871095 804588 91682047%/S2/usr /dev/ad0s3e 1870751 1172006 54908568%/usr /dev/ad0s3g 101630358597 876402 6%/var /dev/ad0s3h 10277074 5916668 353824163%/common procfs 440 100%/proc /dev/md10c 520140 24 478508 0%/tmp d141[2] uname -a FreeBSD d141.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #182: Sun Nov 25 10: 59:43 PST 2001 [EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/LAPTOP_30 W i386 d141[3] ssh freebeast tail /var/log/cvsup-history.log CVSup begin from cvsup13.freebsd.org at Wed Nov 21 03:47:15 PST 2001 CVSup ended from cvsup13.freebsd.org at Wed Nov 21 03:53:35 PST 2001 CVSup begin from cvsup14.freebsd.org at Thu Nov 22 03:47:02 PST 2001 CVSup ended from cvsup14.freebsd.org at Thu Nov 22 03:53:07 PST 2001 CVSup begin from cvsup14.freebsd.org at Fri Nov 23 03:47:02 PST 2001 CVSup ended from cvsup14.freebsd.org at Fri Nov 23 03:53:23 PST 2001 CVSup begin from cvsup14.freebsd.org at Sat Nov 24 03:47:06 PST 2001 CVSup ended from cvsup14.freebsd.org at Sat Nov 24 03:53:47 PST 2001 CVSup begin from cvsup14.freebsd.org at Sun Nov 25 03:47:02 PST 2001 CVSup ended from cvsup14.freebsd.org at Sun Nov 25 03:52:57 PST 2001 d141[4] Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df -l broken
Paul van der Zwan wrote: I noticed the -l option of the df command is broken. It is supposed to print df for local filesystems but on my system it prints nothing at all. I had a quick look at the code , as far as I can tell it uses sysctl to figure out the mounted filesystems but thinks all of them are non-local and ignores them. Using sysctl -a I could not find any entries which looked vaguely like describing a mount.. Paul Could you please test the attached patch ? I did it in a hurry but it may fix the problem. Thanks, Maxime Henrion -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Index: df.c === RCS file: /home/ncvs/src/bin/df/df.c,v retrieving revision 1.32 diff -u -r1.32 df.c --- df.c1 Aug 2001 02:09:09 - 1.32 +++ df.c25 Nov 2001 22:57:49 - @@ -561,7 +561,8 @@ *strptr = ','; free(listptr[i]); } - *(--strptr) = NULL; + if (i 0) + *(--strptr) = NULL; free(listptr); return (str);
Re: df -l broken
David Wolfskill wrote: Date: Sun, 25 Nov 2001 22:41:01 +0100 From: Paul van der Zwan [EMAIL PROTECTED] I noticed the -l option of the df command is broken That differs from my experience: d141[1] df -l Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s3a158783939195216264%/ devfs 110 100%/dev /dev/ad0s1a158767652608080645%/S1 /dev/ad0s1e 1871095 1059572 66183662%/S1/usr /dev/ad0s2a158767 1039454212171%/S2 /dev/ad0s2e 1871095 804588 91682047%/S2/usr /dev/ad0s3e 1870751 1172006 54908568%/usr /dev/ad0s3g 101630358597 876402 6%/var /dev/ad0s3h 10277074 5916668 353824163%/common procfs 440 100%/proc /dev/md10c 520140 24 478508 0%/tmp [...] If my patch is exact, then the bug should manifest itself only if there are no network filesystems mounted. Do you have any network fs mounted on your box ? Thanks, Maxime Henrion -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df output ? (picobsd related)
ufs:fd0a set `df /` ; dev="/dev/$8" How about something like IFS=': '; set `df /`; IFS=' ' dev="/dev/$9" -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: df output ? (picobsd related)
On Mon, 7 Feb 2000, Luigi Rizzo wrote: on 3.4R, when booting, a df / would return the name of the boot device, something like fd0a wd0a... and the like. On a recent -current snap, this returns ufs:fd0a This may be caused by using a not very recent -current snap. I think I fixed this bug ion 1999/11/28. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: df output ? (picobsd related)
On Mon, Feb 07, 2000 at 01:04:27PM +0100, Luigi Rizzo wrote:
and the like. On a recent -current snap, this returns
ufs:fd0a
I used the previous behaviour in picobsd's rc to mount
the file system from the boot device,
set `df /` ; dev="/dev/$8"
echo "Reading /etc from ${dev}..."
mount -o rdonly ${dev} /mnt
unfortunately the "ufs:" prefix breaks the above code.
Any simple shell trick to parse/remove the ufs: prefix ?
Note, i cannot use tr, basename or other progs, they are just not there!
How about dev="/dev/${8#*:}" ?
--
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
