Re: remove df(1) support for mounting filesystems
haha, this is the weirdest functionality I have seen in times. So long for the 'programs that do one thing and do it well' philosophy. :-) axe it! cheers, Ronald. PS: sorry for the twitter-style reply. Van: Mark Johnston Datum: donderdag, 12 november 2020 19:51 Aan: freebsd-current@freebsd.org Onderwerp: remove df(1) support for mounting filesystems Hi, df(1) has the ability to mount character devices in order to collect usage information. This functionality has been deprecated for the past couple of years, since r329092, and is buggy per PR 237368. I propose removing it in 13.0: https://reviews.freebsd.org/D27197 ___ 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" ___ 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"
remove df(1) support for mounting filesystems
Hi, df(1) has the ability to mount character devices in order to collect usage information. This functionality has been deprecated for the past couple of years, since r329092, and is buggy per PR 237368. I propose removing it in 13.0: https://reviews.freebsd.org/D27197 ___ 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 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
"df /" output missing "Filesystem" after r351187 -> r351211
"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 da...@catwhisker.org What, exactly, is the contribution of "health insurance" to health care? See http://www.cat
8.1-release + zfs v15 df(1) hangs
Hi All,
i installed freebsd 8.1-release on my workstation (based on the
8.1-release mfsbsd isos) and I'm now experiencing some strange effects.
A df(1) doesn't return and is not killable and while taking a look
around in my process table, I could find several find's hanging around too.
mhettwer 5976 0.0 0.0 6896 1088 13 D+5:55PM 0:00.00 df -h
mhettwer 5351 0.0 0.0 6896 1088 19 D+1:49PM 0:00.00 df -h
root 215 0.0 0.0 5804 1232 ?? DMon05AM 0:04.29 find
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
root 4139 0.0 0.0 5804 1324 ?? DTue05AM 0:02.38 find
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
root 7305 0.0 0.0 5804 1324 ?? D 5:01AM 0:00.43 find
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
root 73775 0.0 0.0 5804 1232 ?? DFri05AM 0:10.18 find
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
root 94589 0.0 0.0 5804 1232 ?? DSat05AM 0:07.68 find
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
nobody 94746 0.0 0.0 5804 1072 ?? DN Sat06AM 0:07.38 find -s
/ ! ( -fstype zfs ) -prune -or -path /tmp -prune -or -path /usr/tmp
-prune -or -path /var/tmp -prune -or -path /var/db/portsnap -prune -or
-print
root 97430 0.0 0.0 5804 1232 ?? DSun05AM 0:06.02 find
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
I couldn't figure out where they're coming from, but since it seems
there's a new one every night I suspect its coming from a periodic script.
Any ideas how to get rid of those processes?
And yes, I know that zfs V15 isn't in -STABLE for a reason...
# uname -a
# FreeBSD siteop38-1.mobile.rz 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Tue
Aug 3 12:03:02 UTC 2010
r...@siteop38-1.mobile.rz:/usr/obj/usr/src/sys/GENERIC amd64
(I csup'ed to RELENG_8_1 and applied the v15 patch from
http://mfsbsd.vx.sk/ and did a make world)
best regards,
Marian
PS.: For the author of mfsbsd iso's: I like them. Cool! Thanks! :)
___
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: 8.1-release + zfs v15 df(1) hangs
on 18/08/2010 11:23 Marian Hettwer said the following: Hi All, i installed freebsd 8.1-release on my workstation (based on the 8.1-release mfsbsd isos) and I'm now experiencing some strange effects. A df(1) doesn't return and is not killable and while taking a look around in my process table, I could find several find's hanging around too. mhettwer 5976 0.0 0.0 6896 1088 13 D+5:55PM 0:00.00 df -h mhettwer 5351 0.0 0.0 6896 1088 19 D+1:49PM 0:00.00 df -h Can you run procstat -k to see where exactly the processes are stuck? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 8.1-release + zfs v15 df(1) hangs
Hej there, Am 18.08.10 17:18, schrieb Andriy Gapon: on 18/08/2010 11:23 Marian Hettwer said the following: Hi All, i installed freebsd 8.1-release on my workstation (based on the 8.1-release mfsbsd isos) and I'm now experiencing some strange effects. A df(1) doesn't return and is not killable and while taking a look around in my process table, I could find several find's hanging around too. mhettwer 5976 0.0 0.0 6896 1088 13 D+5:55PM 0:00.00 df -h mhettwer 5351 0.0 0.0 6896 1088 19 D+1:49PM 0:00.00 df -h Can you run procstat -k to see where exactly the processes are stuck? for some reason, the stuck df and find processes are gone. And since df works again, I could see a nfs mount which I guessed caused the issue. Hm, so best guess, a hanging nfs mount is not good. I remember I mounted it without any special options. just mount ip:/export /mnt and probably forgot about it. I'll try and reproduce that tomorrow. I would say, a hanging nfs mount shouldn't lead to a hanging around df(1). all the best, Marian ___ 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: 8.1-release + zfs v15 df(1) hangs
on 18/08/2010 22:07 Marian Hettwer said the following: I'll try and reproduce that tomorrow. I would say, a hanging nfs mount shouldn't lead to a hanging around df(1). See df -n. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 8.1-release + zfs v15 df(1) hangs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/18/2010 15:46, Andriy Gapon wrote:
on 18/08/2010 22:07 Marian Hettwer said the following:
I'll try and reproduce that tomorrow. I would say, a hanging nfs mount
shouldn't lead to a hanging around df(1).
See df -n.
Going with this making an addition.
I usually add this to my periodic.conf:
daily_status_disks_df_flags=-h -i -t ufs,zfs
Adding '-c' for a system that has ZFS produces results that are not
correct for a total, but stating it more for reference. It might make
sense to patch df(1) so it looks at the begging portion of the
file-system up to the first '/' and get the value for free and used from
that but this is tricky when refreserved, quota and other properties
come into play and is a little beyond what df is meant for. But that
subject is for another thread.
I do wonder if it would make sense to just split the daily_status_disks*
into daily_status_{FILESYSTEM} to look like this
daily_status_ufs_df_flags etc... and keep daily_status_disks_df to be
defined as daily_status_disks_df=ufs zfs xfs
Ignore random babbling meant to spur thought. ;)
Regards,
- --
jhell,v
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMbIQnAAoJEJBXh4mJ2FR+1lkH/3UbwkUE0L7AbivsIc1bjZA6
R+6lVv80xquXrgxZiMZWAhd40fqaduztM9hWzicL2yEVIsg+lp1WE4IRo2pyUdFs
ZTDsa3RcDpXeTt2NmUdMHefd0RC0aRrrAmf1JGifUs2/UNHpT/5PP1fIl783P71J
z8VFNcGcCmCSUcSdg8I14LDoFAqfbA0DkpTDyYrQVcHmNEp7aBgvJBNF+9/3y4R9
wC6+CbPVy93L3yOmxIfEM88oHtq4zfMRLcNreMAx+bQntzM7bA2xJrXV8Zkt5Jok
RFqE7TScKyE89YulkosSFMs1OK0SwTFDHZdAIO4mM4V9mVcaaZ8iWTiGrlZRxoQ=
=Kf91
-END PGP SIGNATURE-
___
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
df: negative overflow?
Hi, cvs as of Sunday ~11:00am GMT. Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/ad0s2a 484 70 374 16% / devfs 0 0 0 100% /dev /dev/md0 62 0 57 0% /tmp /dev/ad0s2d 4958 893 3668 20% /home /dev/ad0s2f 4958 3319 1241 73% /usr /dev/ad0s2g 16374 12841 15% /usr/local /dev/ad0s2e 989 946 36028797018963931 104% /var Filesystem Size Used Avail Capacity Mounted on /dev/ad0s2a 484M 71M 375M 16% / devfs 1.0K 1.0K 0B 100% /dev /dev/md0 63M 8.0K 58M 0% /tmp /dev/ad0s2d 4.8G 893M 3.6G 20% /home /dev/ad0s2f 4.8G 3.2G 1.2G 73% /usr /dev/ad0s2g 16G 2.2G 13G 15% /usr/local /dev/ad0s2e 989M 947M -36.4M 104% /var -- Melvyn pgp0.pgp Description: signature
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
df and amd expected behavior
under 4-STABLE I get the up-till-now behavior where a df -k shows you amd's pid, pid@hostname:/mountpoint under 5-CURRENT it won't show up unless I type df -ak. is the behavior in 5.0 correct? df's man page says: -a Show all mount points, including those that were mounted with the MNT_IGNORE flag. so the answer is very probably, yes. but, some people will confuse expected vs correct so it should be mentioned in the release notes. also, since there's a df -l option PR27319 can be closed. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/27319 --clark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
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
df -l broken
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 -- I have discovered the art of deceiving diplomats. I tell them the truth and they never believe me. -- Camillo Di Cavour 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: bin/19635: add -c for grand total to df(1), like du(1)does
Brad Knowles [EMAIL PROTECTED] writes: At 9:21 PM -0400 2000/7/3, Will Andrews wrote: Does anyone else here think this is a good idea? If you're looking for votes, you've got mine. BTW, will this play nicely with -h? Consider me stupid if you yes since all internal values are counted in bytes as I remember me. juste the output is affected by -h or whatever option. -c just add a summary line. PS : take care, my email address have changed. no more citeweb.net (not reliable) nor poboxe.com (no more free). thanks. Cyrille. -- home: mailto:[EMAIL PROTECTED] UNIX is user-friendly; it's just particular work: mailto:[EMAIL PROTECTED] about who it chooses to be friends with. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
/bin/df set-gid operator
Hi, This is probably the wrong list, but I have no idea where else to ask, and -current is also affected, so ... I'm wondering why /bin/df is set-gid to the operator group by default. I have tried to remove the s bit, and it is still working fine. Looking at the source code didn't give me a clue either. -1- Am I missing something? What? -2- If I'm not missing anything, then shouldn't the BINMODE line be removed from src/bin/df/Makefile? -3- Shall I send-pr a patch? :-) Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 Mnchen Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/df set-gid operator
On Sat, 21 Apr 2001, Oliver Fromme wrote: I'm wondering why /bin/df is set-gid to the operator group by default. It's to df filesystems that aren't mounted. Try "df /dev/ad0s1a" (or whatever) as user nobody with chmod 555 /bin/df. -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/df set-gid operator
Paul Herman [EMAIL PROTECTED] wrote: On Sat, 21 Apr 2001, Oliver Fromme wrote: I'm wondering why /bin/df is set-gid to the operator group by default. It's to df filesystems that aren't mounted. Try "df /dev/ad0s1a" (or whatever) as user nobody with chmod 555 /bin/df. Ah, thanks for clueing me. :-) I didn't know that unprivileged users are supposed to be allowed to use df on non-mounted filesystems. I think I'll keep it at mode 555 on my machines. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 Mnchen Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/df set-gid operator
On Sat, 21 Apr 2001, Oliver Fromme wrote:
Paul Herman [EMAIL PROTECTED] wrote:
On Sat, 21 Apr 2001, Oliver Fromme wrote:
I'm wondering why /bin/df is set-gid to the operator group
by default.
It's to df filesystems that aren't mounted. Try "df /dev/ad0s1a" (or
whatever) as user nobody with chmod 555 /bin/df.
Ah, thanks for clueing me. :-)
I didn't know that unprivileged users are supposed to be
allowed to use df on non-mounted filesystems.
I think I'll keep it at mode 555 on my machines.
This brings up a slightly related question: Now that "cooked" block
devices have been abolished, wouldn't it be a good idea to get rid of
the quick mount(2)/umount(2) of /tmp/df.XX to stat the file
system? Something like the following patch.
Not that it should ever get called anyway...
-Paul.
Index: df.c
===
RCS file: /home/ncvs/src/bin/df/df.c,v
retrieving revision 1.23.2.1
diff -u -r1.23.2.1 df.c
--- df.c2000/06/13 03:19:40 1.23.2.1
+++ df.c2001/04/21 18:02:18
@@ -208,40 +208,6 @@
} else if ((stbuf.st_mode S_IFMT) == S_IFCHR) {
rv = ufs_df(*argv, maxwidth) || rv;
continue;
- } else if ((stbuf.st_mode S_IFMT) == S_IFBLK) {
- if ((mntpt = getmntpt(*argv)) == 0) {
- mdev.fspec = *argv;
- mntpath = strdup("/tmp/df.XX");
- if (mntpath == NULL) {
- warn("strdup failed");
- rv = 1;
- continue;
- }
- mntpt = mkdtemp(mntpath);
- if (mntpt == NULL) {
- warn("mkdtemp(\"%s\") failed", mntpath);
- rv = 1;
- free(mntpath);
- continue;
- }
- if (mount("ufs", mntpt, MNT_RDONLY,
- mdev) != 0) {
- rv = ufs_df(*argv, maxwidth) || rv;
- (void)rmdir(mntpt);
- free(mntpath);
- continue;
- } else if (statfs(mntpt, statfsbuf) == 0) {
- statfsbuf.f_mntonname[0] = '\0';
- prtstat(statfsbuf, maxwidth);
- } else {
- warn("%s", *argv);
- rv = 1;
- }
- (void)unmount(mntpt, 0);
- (void)rmdir(mntpt);
- free(mntpath);
- continue;
- }
} else
mntpt = *argv;
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /bin/df set-gid operator
Sorry to follow up on my own mail... On Sat, 21 Apr 2001, Paul Herman wrote: This brings up a slightly related question: Now that block devices have been abolished, wouldn't it be a good idea to get rid of the quick mount(2)/umount(2) of /tmp/df.XX to stat the file system? I see now that block type devices still pop up everywhere in the VFS system, so I'll just forget this and leave it up to the team that may someday totaly remove block device support from the kernel -- if that ever will happen. :-) -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/df set-gid operator
On Sat, 21 Apr 2001, Paul Herman wrote:
This brings up a slightly related question: Now that "cooked" block
devices have been abolished, wouldn't it be a good idea to get rid of
the quick mount(2)/umount(2) of /tmp/df.XX to stat the file
system? Something like the following patch.
No. This code is just unreachable because it still hasn't be changed
to mount "raw" block devices.
Note that in 4.4BSD, the mount(2)/unmount(2) code works without df
being setgid operator provided group operator can read the devices,
since mount(2) doesn't require superuser privilege in 4.4BSD. In
FreeBSD, mount privilege is controlled by the vfs.usermount sysctl
(default: off), so df must still be setgid operator to work on devices.
The mount() method is better because can work on work on all types of
filesystems that the kernel understands, while ufs_df() only works
for ufs.
Untested fixes:
Index: df.c
===
RCS file: /home/ncvs/src/bin/df/df.c,v
retrieving revision 1.24
diff -c -2 -r1.24 df.c
*** df.c2000/06/03 20:17:39 1.24
--- df.c2001/04/21 18:52:52
***
*** 108,112
voidusage __P((void));
! int aflag = 0, hflag, iflag, nflag;
structufs_args mdev;
--- 108,112
voidusage __P((void));
! int aflag, hflag, iflag, nflag;
structufs_args mdev;
***
*** 120,125
long mntsize;
int ch, err, i, maxwidth, rv, width;
! char *mntpt, *mntpath, **vfslist;
vfslist = NULL;
while ((ch = getopt(argc, argv, "abgHhikmnPt:")) != -1)
--- 120,126
long mntsize;
int ch, err, i, maxwidth, rv, width;
! char *fstype, *mntpath, *mntpt, **vfslist;
+ fstype = "ufs";
vfslist = NULL;
while ((ch = getopt(argc, argv, "abgHhikmnPt:")) != -1)
***
*** 163,166
--- 164,168
if (vfslist != NULL)
errx(1, "only one -t option may be specified.");
+ fstype = optarg;
vfslist = makevfslist(optarg);
break;
***
*** 206,213
continue;
}
! } else if ((stbuf.st_mode S_IFMT) == S_IFCHR) {
! rv = ufs_df(*argv, maxwidth) || rv;
! continue;
! } else if ((stbuf.st_mode S_IFMT) == S_IFBLK) {
if ((mntpt = getmntpt(*argv)) == 0) {
mdev.fspec = *argv;
--- 208,212
continue;
}
! } else if (S_ISBLK(stbuf.st_mode) || S_ISCHR(stbuf.st_mode)) {
if ((mntpt = getmntpt(*argv)) == 0) {
mdev.fspec = *argv;
***
*** 225,229
continue;
}
! if (mount("ufs", mntpt, MNT_RDONLY,
mdev) != 0) {
rv = ufs_df(*argv, maxwidth) || rv;
--- 224,228
continue;
}
! if (mount(fstype, mntpt, MNT_RDONLY,
mdev) != 0) {
rv = ufs_df(*argv, maxwidth) || rv;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Changing df [device] behaviour (Re: /bin/df set-gid operator)
On Sun, 22 Apr 2001, Bruce Evans wrote: In FreeBSD, mount privilege is controlled by the vfs.usermount sysctl (default: off), so df must still be setgid operator to work on devices. The mount() method is better because can work on work on all types of filesystems that the kernel understands, while ufs_df() only works for ufs. [patch] Although I like the idea of being able to df unmounted, non-ufs filesystems, I think the tradeoff might be too harsh. Non-root users aren't allowed to mount(2) at all if vfs.usermount=0, operator or no operator -- that is, in this case, df would fail for non-root users. -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
hi everybody and Happy New Year, anybody to commit http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19635 ? one of the reasons it was not commited was due to an overflow problem which has been fixed since. thanks by advance.. Cyrille. -- home: mailto:[EMAIL PROTECTED] work: mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
Paul Herman [EMAIL PROTECTED] writes: On Thu, 6 Jul 2000, Bill Fumerola wrote: [snip] Filesystem1K-blocks UsedAvail Capacity Mounted on /dev/ad0s2a 44650330922 379861 8%/ /dev/ad0s9e 1453615 758910 57841657%/usr /dev/ad0s9f 968983 357403 53406240%/usr/local /dev/ad0s9g 242239 9945 212915 4%/var /dev/ad0s9h 2013515 1242447 60998767%/u01 procfs440 100%/proc Heh? What's this?242239 9945 212915 4%/mnt total 1581144 505684 99514034%/mnt2 total 1391380 414168 90652831%/mnt3 bash-2.03# Hee, hee. Yes, this is probably no big deal (and not put forth as any strong argument for not commiting this) but who knows what some cronjob scripts might expect. Hmmm, let me give constructive criticism a shot and see how far it goes: humm! you are looking for a small bug (the beast :) this problem also exists w/ du -c... # cp -rp /etc/defaults total # du -c total 69 total 69 total so, your argumentation isn't "viable" (in french, don't know the translation in english, sorry). if you prefer, say "total:" inseatd of just "total" since it's not possible to remote mount something like this. but what about du -c in this case... Perhaps if it were expected that the "df -c" output were completly different? Then "total" would be less likely to be counted as some other filesystem by mistake? Perhaps something along the lines: bash-2.0.3# df -c /usr /usr/local Totals for: /usr /usr/local 1K-Blocks:2422598 Used: 1116313 Avail:1306285 Capacity: 46% Dunno how that would go over with the purists, though... after all 'df' is in one of the holiest of directories... /bin. g Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "no-spam." pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "no-spam." to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
Sheldon Hearn [EMAIL PROTECTED] writes: On Tue, 04 Jul 2000 15:47:25 -0400, Will Andrews wrote: On Tue, Jul 04, 2000 at 04:06:46PM +0200, Sheldon Hearn wrote: My only objection is that it seems to produce useless values. Can you think of a use for these grand totals? They are helpful for monitoring total space; I would use them in administrative scripts to watch my space. Okay, then. Let me be more specific. How is the notion of "total space" useful? :-) statistics for backup tapes needed. for instance, at work, there is a big restructuration of departements. so, there are 10 gigs (about 300 GB) to move from servers to others. of course, I use some kind of awk scripts to do the same things. but, under FreeBSD, I saw that du has a -c option to do that job. why df couln't have the same option to do the same job ? for every scripts I write, I do it the more portable as possible I can. but if I can optimize the job, I'll do it. another way to say that is : how is it possible you don't like this option to df for any reason, while you have accepted the same option to du ? Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "no-spam." pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "no-spam." to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Wed, 5 Jul 2000, Bill Fumerola wrote: On Tue, Jul 04, 2000 at 09:56:43PM +0200, Blaz Zupan wrote: this number is completely useless to me. I have to agree with Sheldon, where is the use to this number? Think about doing something like $ df -c/disk0 /disk1 /disk2 ... /diskX To just monitor a cluster of disks. I'm all for adding options to get features you can't otherwise get (even *IF* the use of "total" is debatable), but c'mon, this is an awk one-liner. I would agree with Sheldon as well. Let this one go. -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
As a side issue, can anyone explain these peculiar results from df(1)'s huamn-readable (-h) output: Filesystem Size Used Avail Capacity Mounted on mfs:26 87M11K80M 0%/tmp /dev/ad0s1f 1.2G 934M 241M80%/usr /dev/ad0s1e 193M92M86M52%/var /dev/ccd0c 1.8G 786M 900M47%/a /dev/ad1s1e 1.3G 728M 474M61%/b procfs 4.0K 4.0K 0B 100%/proc rodent.ops:/home/ncvs 3.4G 3.1G36M99%/usr/home/ncvs In particular, I can't believe that 87M - 11K == 80M (I'd expect 86M or 87M). Nor is it credible that 1.8G - 786 == 900M (I'd expect 1057M or 1G). Am I being obtuse, and if so could someone explain my folly? :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
+[ Sheldon Hearn ]- | | As a side issue, can anyone explain these peculiar results from df(1)'s | huamn-readable (-h) output: | | Filesystem Size Used Avail Capacity Mounted on | mfs:26 87M11K80M 0%/tmp | /dev/ad0s1f 1.2G 934M 241M80%/usr | /dev/ad0s1e 193M92M86M52%/var | /dev/ccd0c 1.8G 786M 900M47%/a | /dev/ad1s1e 1.3G 728M 474M61%/b | procfs 4.0K 4.0K 0B 100%/proc | rodent.ops:/home/ncvs 3.4G 3.1G36M99%/usr/home/ncvs | | In particular, I can't believe that 87M - 11K == 80M (I'd expect 86M or | 87M). Nor is it credible that 1.8G - 786 == 900M (I'd expect 1057M or | 1G). | | Am I being obtuse, and if so could someone explain my folly? :-) Those are block available to non-superuser I think, not "just available" There's some amount reserved (10% ?). -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Thu, 06 Jul 2000 20:48:46 +1000, Andrew Kenneth Milton wrote: Those are block available to non-superuser I think, not "just available" There's some amount reserved (10% ?). Duh. Classic mistake in disguise. :-) Sorry to trouble. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1)does
At 12:41 PM +0200 2000/7/6, Sheldon Hearn wrote: Filesystem Size Used Avail Capacity Mounted on mfs:26 87M11K80M 0%/tmp /dev/ad0s1f 1.2G 934M 241M80%/usr /dev/ad0s1e 193M92M86M52%/var /dev/ccd0c 1.8G 786M 900M47%/a /dev/ad1s1e 1.3G 728M 474M61%/b procfs 4.0K 4.0K 0B 100%/proc rodent.ops:/home/ncvs 3.4G 3.1G36M99%/usr/home/ncvs In particular, I can't believe that 87M - 11K == 80M (I'd expect 86M or 87M). Nor is it credible that 1.8G - 786 == 900M (I'd expect 1057M or 1G). You're ignoring the fact that "Size" is the total physical size of the device, while "Used", "Avail", and "Capacity" take into account the 10% (or whatever) overhead that is typically left unallocated for performance reasons. Thus, when "Capacity" shows that ~110% is used, and "Used" == "Size", then you are really and truly completely full on that device. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Large disks (was Re: bin/19635: add -c for grand total to df(1))
On Thu, Jul 06, 2000 at 12:58:27PM +0200, Brad Knowles wrote: [whole discussion about df -h output snipped] You're ignoring the fact that "Size" is the total physical size of the device, while "Used", "Avail", and "Capacity" take into account the 10% (or whatever) overhead that is typically left unallocated for performance reasons. Maybe this isn't the right list to ask, but stepping into this: I bought a 30G drive recently, and I was wondering if the 10% 'rule' for performance is still really needed. I mean, I lose 3 _gigs_ of storage space, and otherwise the performance detoriates? That doesn't make sense to me. I am running now with reserved set to 2% (on my /home, not on smaller / /usr of course) and haven't noticed anything of performance loss; of course I haven't managed to fill that ~27G in the short time I have this setup ;) Which also leads me to the question: is it desirable, given those large disks, to have a finer grain of control over reserved space, for example setting reserved space to 2.5% or whatever? Or can this be done already? In the hopes that someone can enlighten me... --Stijn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Thu, 06 Jul 2000 10:26:00 -0400, Brian Hechinger wrote: beancounters don't understand that computers can have more than one disk let alone multiple slices. so it gives a nice total number to slap into a pie chart so that you can requisition more hard drives for your machines. This argument from Bill Fumerola is what swayed me enough to bring me back to being neutral. ;-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Large disks (was Re: bin/19635: add -c for grand total to df(1))
On Thu, 6 Jul 2000 13:18:40 +0200, Stijn Hoop [EMAIL PROTECTED] said: Maybe this isn't the right list to ask, but stepping into this: I bought a 30G drive recently, and I was wondering if the 10% 'rule' for performance is still really needed. I mean, I lose 3 _gigs_ of storage space, and otherwise the performance detoriates? That doesn't make sense to me. Yes. The efficiency of the hashing mechanism used to lay out new blocks on the disk depends only on what fraction of the disk is used, not how much space that represents. (On the other hand, it is unlikely that you are significantly stressing the allocator in any meaningful way.) If you're concerned about wasted disk space, there's a lot to be gained by fiddling with the block sizes, bytes per inode, and other layout parameters. Your 30-GB disk probably has a zillion cylinder groups, which is far too many to actually be helpful in disk layout. When creating a large filesystem, it pays to increase the `-c' parameter as high as newfs will permit. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Thu, 6 Jul 2000, Sheldon Hearn wrote:
On Thu, 06 Jul 2000 10:26:00 -0400, Brian Hechinger wrote:
beancounters don't understand that computers can have more than one disk let
alone multiple slices. so it gives a nice total number to slap into a pie
chart so that you can requisition more hard drives for your machines.
This argument from Bill Fumerola is what swayed me enough to bring me
back to being neutral. ;-)
First of all I'll state, I (just some FreeBSD user) am neutral on this
as well -- which means, I wouldn't complain if it gets commited. :)
There's just one thing nagging me:
I still can't get past the fact that this can all be done very simply
and much better with available tools. I see this option similar to,
for example, "why not have an option to print only the 'Used' column."
If this were to be commited, there would be no net gain. (No net
loss, either.)
Naturally, "no reason not to put it in" is most certainly *not* a
reason to put it in. I would like to hear some to sway me one way or
the other.
Spoiler:
df /disk1 /disk2 | \
awk '/^\// {t+=$2;u+=$3;} END { print "Total:", t,u,t-u,u*100/t; }'
...and "slaping 'df -c' into a pie chart" usually intails running it
through some parser like this, anyway... or?
-Paul.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Thu, Jul 06, 2000 at 06:09:54PM +0200, Paul Herman wrote: Naturally, "no reason not to put it in" is most certainly *not* a reason to put it in. I would like to hear some to sway me one way or the other. How about precedent: du -c. "Hey, we could have used an awk script with du(1) too!!" -- Will Andrews [EMAIL PROTECTED] [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Thu, Jul 06, 2000 at 06:09:54PM +0200, Paul Herman wrote:
Naturally, "no reason not to put it in" is most certainly *not* a
reason to put it in. I would like to hear some to sway me one way or
the other.
Spoiler:
df /disk1 /disk2 | \
awk '/^\// {t+=$2;u+=$3;} END { print "Total:", t,u,t-u,u*100/t; }'
...and "slaping 'df -c' into a pie chart" usually intails running it
through some parser like this, anyway... or?
[hawk-billf] /home/billf du -s /usr/src/sys/i386 /usr/ports/math | \
awk '{t+=$1; print $0} END { print t, "\ttotal" }'
6282/usr/src/sys/i386
15288 /usr/ports/math
21570 total
[hawk-billf] /home/billf du -cs /usr/src/sys/i386 /usr/ports/math
6282/usr/src/sys/i386
15288 /usr/ports/math
21570 total
Precedence.
--
Bill Fumerola - Network Architect / Computer Horizons Corp - CHIMES
e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Thu, 6 Jul 2000, Bill Fumerola wrote: On Thu, Jul 06, 2000 at 06:09:54PM +0200, Paul Herman wrote: Naturally, "no reason not to put it in" is most certainly *not* a reason to put it in. I would like to hear some to sway me one way or the other. [...] [hawk-billf] /home/billf du -cs /usr/src/sys/i386 /usr/ports/math 6282/usr/src/sys/i386 15288 /usr/ports/math 21570 total Precedence. OK, I'm with ya, I could go with Precedence, but you have to admit, it's pretty weak. Just because "it's been done before"...? Hmmm. Well, I was hoping for something concrete about the program like "because this option gives us something never seen by sysadmins before without massive contortions", or "this option does correctly what XXX program never could..." etc. Unfortunately, I can't think of any myself. For what one person's opinion is worth, I still haven't heard a strong reason for this. Sorry guys, you can still color me undecided on this one. :( On a side note, look what I found: bash-2.03# cd bash-2.03# ln -s /dev/ad0s6e "Heh? What's this?" bash-2.03# mount "Heh? What's this?" /mnt bash-2.03# ln -s /dev/ad0s6f total bash-2.03# mount total /mnt2 bash-2.03# mkdir whut_thuh_hey; cd whut_thuh_hey bash-2.03# ln -s /dev/ad0s6g total bash-2.03# mount total /mnt3 bash-2.03# df Filesystem1K-blocks UsedAvail Capacity Mounted on /dev/ad0s2a 44650330922 379861 8%/ /dev/ad0s9e 1453615 758910 57841657%/usr /dev/ad0s9f 968983 357403 53406240%/usr/local /dev/ad0s9g 242239 9945 212915 4%/var /dev/ad0s9h 2013515 1242447 60998767%/u01 procfs440 100%/proc Heh? What's this?242239 9945 212915 4%/mnt total 1581144 505684 99514034%/mnt2 total 1391380 414168 90652831%/mnt3 bash-2.03# Hee, hee. Yes, this is probably no big deal (and not put forth as any strong argument for not commiting this) but who knows what some cronjob scripts might expect. Hmmm, let me give constructive criticism a shot and see how far it goes: Perhaps if it were expected that the "df -c" output were completly different? Then "total" would be less likely to be counted as some other filesystem by mistake? Perhaps something along the lines: bash-2.0.3# df -c /usr /usr/local Totals for: /usr /usr/local 1K-Blocks: 2422598 Used: 1116313 Avail: 1306285 Capacity: 46% Dunno how that would go over with the purists, though... after all 'df' is in one of the holiest of directories... /bin. g -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Large disks (was Re: bin/19635: add -c for grand total to df(1))
On Thu, 6 Jul 2000, Garrett Wollman wrote: When creating a large filesystem, it pays to increase the `-c' parameter as high as newfs will permit. I always do this manually. It should probably be the default for sufficiently large filesystems. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Tue, Jul 04, 2000 at 09:56:43PM +0200, Blaz Zupan wrote: Ok, so let's say my / is 100% full, my /usr is 50% full and my /var is 20% full. What would the total number tell me? That my file systems are 56.6% full. That tells me nothing about my root file system running out of space, so this number is completely useless to me. I have to agree with Sheldon, where is the use to this number? If you would use the "total" field to monitor diskusage on / then you get what you deserve. Think about doing something like $ df -c/disk0 /disk1 /disk2 ... /diskX To just monitor a cluster of disks. -- Bill Fumerola - Network Architect / Computer Horizons Corp - CHIMES e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1)does
At 9:21 PM -0400 2000/7/3, Will Andrews wrote: Does anyone else here think this is a good idea? If you're looking for votes, you've got mine. BTW, will this play nicely with -h? Consider me stupid if you like, but I've recently been re-re-re-re-reading the man pages for df(1), and ran across this option I had never heard of before, and I quite like the way it adaptively summarizes the information. Of course, now that you've got me started, I have to go re-re-re-re-read the du(1) man page, too. ;-) Thanks! -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Mon, 03 Jul 2000 21:21:52 -0400, Will Andrews wrote: Does anyone else here think this is a good idea? If so, I'd like to merge this in -CURRENT and MFC before 4.1-RELEASE. It seems like a fairly nice addition to df(1), and can be useful for system accounting. My only objection is that it seems to produce useless values. Can you think of a use for these grand totals? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Tue, Jul 04, 2000 at 04:06:46PM +0200, Sheldon Hearn wrote: My only objection is that it seems to produce useless values. Can you think of a use for these grand totals? They are helpful for monitoring total space; I would use them in administrative scripts to watch my space. Granted, this job could be done by shell scripts.. but I think it would be useful in df(1). -- Will Andrews [EMAIL PROTECTED] [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
They are helpful for monitoring total space; I would use them in administrative scripts to watch my space. Ok, so let's say my / is 100% full, my /usr is 50% full and my /var is 20% full. What would the total number tell me? That my file systems are 56.6% full. That tells me nothing about my root file system running out of space, so this number is completely useless to me. I have to agree with Sheldon, where is the use to this number? Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia E-mail: [EMAIL PROTECTED], Tel: +386-2-320-6320, Fax: +386-2-320-6325 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Tue, 04 Jul 2000 15:47:25 -0400, Will Andrews wrote: On Tue, Jul 04, 2000 at 04:06:46PM +0200, Sheldon Hearn wrote: My only objection is that it seems to produce useless values. Can you think of a use for these grand totals? They are helpful for monitoring total space; I would use them in administrative scripts to watch my space. Okay, then. Let me be more specific. How is the notion of "total space" useful? :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Tue, Jul 04, 2000 at 10:34:41PM +0200, Sheldon Hearn wrote: Okay, then. Let me be more specific. How is the notion of "total space" useful? :-) Tells you when it's time to get new hard drives? I guess the originator of the PR should provide a reason. =\ -- Will Andrews [EMAIL PROTECTED] [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Tue, 04 Jul 2000 22:34:41 +0200, Sheldon Hearn wrote: They are helpful for monitoring total space; I would use them in administrative scripts to watch my space. Okay, then. Let me be more specific. How is the notion of "total space" useful? :-) exactly. It will be more of statistical value rather than really useful, I think. But I don't see a reason not to merge it, anyway. -- Robert Drehmel [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Sun, Jul 02, 2000 at 07:58:17AM +0200, [EMAIL PROTECTED] wrote: Synopsis: add -c for grand total to df(1), like du(1) does Description: sample of output : # df -c Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/da0s1a 1904559 1249983 50221271%/ /dev/da1s1c 2031922 1336326 53304371%/disk2 /dev/da2s1a 1904559 1484367 26782885%/disk1 /dev/da3s1a 1904559 1414623 33757281%/disk4 procfs 440 100%/proc total 7745603 5485303 164065577% Does anyone else here think this is a good idea? If so, I'd like to merge this in -CURRENT and MFC before 4.1-RELEASE. It seems like a fairly nice addition to df(1), and can be useful for system accounting. -- Will Andrews [EMAIL PROTECTED] [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Tue, Jul 04, 2000 at 03:32:11PM +1000, Andy Farkas wrote: My only suggestion is to put a dashed line above the totals in order to clearly say they are totals (like I did below). That might be nice, but I object on the grounds that it isn't consistent with du -c. -- Will Andrews [EMAIL PROTECTED] [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs/df bug?
On Wed, Jun 21, 2000 at 09:50:57PM +0200, Cyrille Lefevre wrote: well, what about exporting a directory w/o exporting a filesystem ? which is usefull somethimes. possible too ? Add the directory to exports and HUP mountd. (I think that in the kernel the exports are at a filesystem level, so while you can export any directory a naughty client can do "cd ../../../.." and find their way back up to the top of the exported filesystem. Most people's NFS clients won't allow you to do this, but you could write your own client to do it). David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs/df bug?
Thus spake Kevin Day ([EMAIL PROTECTED]): This is probably similar to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=6187 Not sure. I don't think so. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs/df bug?
Thus spake Ben Smithurst ([EMAIL PROTECTED]): neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn You probably have a symlink in the client path somewhere. Is /usr/home a symlink to /home or something? drwxr-xr-x 7 root wheel 512 6 Mär 14:45 /usr/home/ lrwxrwxrwx 1 root wheel 9 27 Feb 20:33 /home@ - /usr/home However, that is not the point. After having rebootet: Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad2a 396895 2896187552679%/ /dev/ad2e 5257421 4632631 20419796%/usr procfs 440 100%/proc /dev/ad0s1 4224828 3755464 46936489%/dos neutron:/usr/ports 496367 183788 27287040%/usr/ports neutron:/usr/ports-distfiles 2482878 1191972 109227652%/usr/ports-distfiles neutron:/usr/home/ncvs 992439 9615493089097%/usr/home/ncvs neutron:/usr/src928695 482050 37235056%/usr/src neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/www/docs 297423 168669 10496162%/www neutron:/usr/doc 2482878 1191972 109227652%/usr/doc And now, some mount -a later: root:~ $ mount -a nfs: can't access /var: Permission denied root:~ $ mount -a nfs: can't access /var: Permission denied root:~ $ mount -a nfs: can't access /var: Permission denied Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad2a 396895 2896187552679%/ /dev/ad2e 5257421 4632631 20419796%/usr procfs 440 100%/proc /dev/ad0s1 4224828 3755464 46936489%/dos neutron:/usr/ports 496367 183788 27287040%/usr/ports neutron:/usr/ports-distfiles 2482878 1191972 109227652%/usr/ports-distfiles neutron:/usr/home/ncvs 992439 9615493089097%/usr/home/ncvs neutron:/usr/src928695 482050 37235056%/usr/src neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/www/docs 297423 168669 10496162%/www neutron:/usr/doc 2482878 1191972 109227652%/usr/doc neutron:/usr/home/ncvs 992439 9615493089097%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9615493089097%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9615493089097%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn First of all, I'm going to correct the export problem, which I kept because of this nice bug :) Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs/df bug?
On Wed, Jun 21, 2000 at 02:35:51AM +0200, Cyrille Lefevre wrote: why there isn't an exportfs command as most unices have ? "killall -HUP mountd" or "mount -u /" both work. This is mentioned in the mountd man page, but should probably also be mentioned in the exports man page. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs/df bug?
Alexander Langer wrote: You probably have a symlink in the client path somewhere. Is /usr/home a symlink to /home or something? drwxr-xr-x 7 root wheel 512 6 Mär 14:45 /usr/home/ lrwxrwxrwx 1 root wheel 9 27 Feb 20:33 /home@ - /usr/home ok, that's not it, the /home symlink shouldn't matter... Or are any of the affected directories (brenn, mp3, ncvs) symlinks? Or maybe your /etc/fstab lists /home/foo instead of /usr/home/foo? However, that is not the point. Well, if symlinks are involved I think this is a known bug. Would you care to fix it? :-) Whether it's a bug in the mount(8) program, the mount(2) syscall, or somewhere deeper, I don't know. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
Re: mount_nfs/df bug?
David Malone [EMAIL PROTECTED] writes: On Wed, Jun 21, 2000 at 02:35:51AM +0200, Cyrille Lefevre wrote: why there isn't an exportfs command as most unices have ? "killall -HUP mountd" or "mount -u /" both work. This is mentioned in the mountd man page, but should probably also be mentioned in the exports man page. well, what about exporting a directory w/o exporting a filesystem ? which is usefull somethimes. possible too ? Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "no-spam." pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "no-spam." to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs/df bug?
Hello! Today I wanted to add a new NFS to my /etc/fstab, but forgot to add it to /etc/exports on the server. However, I did mount -a several times and always got a "Permission denied" for the last one. Now look what I have here: Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad2a 396895 2919047324080%/ /dev/ad2e 5257421 4626154 21067496%/usr procfs 440 100%/proc /dev/ad0s1 4224828 3755464 46936489%/dos neutron:/usr/ports 496367 3634489321080%/usr/ports neutron:/usr/ports-distfiles 2482878 1191660 109258852% /usr/ports-distfiles neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/src928695 482371 37202956%/usr/src neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/www/docs 297423 168669 10496162%/www neutron:/usr/doc 2482878 1191660 109258852%/usr/doc neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn Cute, isn't it? Not yet discovered why. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message This is probably similar to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=6187 -- Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mount_nfs/df bug?
Hello! Today I wanted to add a new NFS to my /etc/fstab, but forgot to add it to /etc/exports on the server. However, I did mount -a several times and always got a "Permission denied" for the last one. Now look what I have here: Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad2a 396895 2919047324080%/ /dev/ad2e 5257421 4626154 21067496%/usr procfs 440 100%/proc /dev/ad0s1 4224828 3755464 46936489%/dos neutron:/usr/ports 496367 3634489321080%/usr/ports neutron:/usr/ports-distfiles 2482878 1191660 109258852%/usr/ports-distfiles neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/src928695 482371 37202956%/usr/src neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/www/docs 297423 168669 10496162%/www neutron:/usr/doc 2482878 1191660 109258852%/usr/doc neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn Cute, isn't it? Not yet discovered why. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs/df bug?
FreeBSD cichlids.cichlids.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Jun 14 22:25:49 CEST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/cichlids i386 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs/df bug?
Alexander Langer [EMAIL PROTECTED] writes: Today I wanted to add a new NFS to my /etc/fstab, but forgot to add it to /etc/exports on the server. However, I did mount -a several times and always got a "Permission denied" for the last one. why there isn't an exportfs command as most unices have ? Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "no-spam." pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "no-spam." to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs/df bug?
Alexander Langer wrote: neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn You probably have a symlink in the client path somewhere. Is /usr/home a symlink to /home or something? -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
df output ? (picobsd related)
Hi,
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
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 suggestion on how to proceed ? I could of course put some extra
entries on fstab so that i can write
set `df /` ; filesystem="/$8"
mount -o rdonly ${filesystem}
but this requires having entries on the filesystem etc. etc.
Any simple shell trick to parse/remove the ufs: prefix ?
Note, i cannot use tr, basename or other progs, they are just not there!
cheers
luigi
---+-
Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
Mobile +39-347-0373137
---+-
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
