root@V490-1 # df -k 问题

sun_sm

root@V490-1 # df -k
df: /etc/mnttab 中的行占过多的字段    这是为什么那？
root@V490-1 # more /etc/mnttab
/dev/md/dsk/d0  /       ufs     rw,intr,largefiles,logging,xattr,onerror=panic,s
uid,dev=1540000 1164545432
/proc   /proc   proc    dev=52c0000     1164545431
mnttab  /etc/mnttab     mntfs   dev=5380000     1164545431
fd      /dev/fd fd      rw,suid,dev=53c0000     1164545432
/dev/md/dsk/d4  /var    ufs     rw,intr,largefiles,logging,xattr,onerror=panic,s
uid,dev=1540004 1164545465
swap    /var/run        tmpfs   xattr,dev=1     1164545465
swap    /tmp    tmpfs   xattr,dev=2     1164545472
/dev/md/dsk/d3  /opt    ufs     rw,intr,largefiles,logging,xattr,onerror=panic,s
uid,dev=1540003 1164545473
/dev/md/dsk/d6  /export/home    ufs     rw,intr,largefiles,logging,xattr,onerror
=panic,suid,dev=1540006 1164545475
-hosts  /net    autofs  indirect,nosuid,ignore,nobrowse,dev=5540001     11645454
78
auto_home       /home   autofs  indirect,ignore,nobrowse,dev=5540002    11645454
78
-xfn    /xfn    autofs  indirect,ignore,dev=5540003     1164545478
/dev/md/dsk/d55 /global/.devices/node@2 ufs     rw,intr,largefiles,logging,noquo
ta,global,xattr,nodfratime,onerror=panic,suid,dev=1540037       1164545479
/dev/md/dsk/d5  /global/.devices/node@1 ufs     rw,intr,largefiles,logging,noquo
ta,global,xattr,nodfratime,onerror=panic,suid,dev=1540005       1164545479
V490-1:vold(pid2366)    /vol    nfs     ignore,noquota,dev=5500001      11645455
85
/dev/md/lotus-set/dsk/d101      /oadata ufs     rw,intr,largefiles,logging,xattr
,onerror=panic,suid,dev=1542065 1207742957
-xfn/_thisorgunit       /xfn/_thisorgunit       autofs  ignore,nest,dev=5540523
1225239827
-xfn/_thisorgunit/_service      /xfn/_thisorgunit/_service      autofs  ignore,n
est,dev=5540524 1225239827
-xfn/_thisorgunit/_service/printer      /xfn/_thisorgunit/_service/printer
autofs  ignore,nest,dev=5540525 1225239827
-xfn/_thisorgunit/service       /xfn/_thisorgunit/service       autofs  ignore,n
est,dev=5540526 1225239827
-xfn/_thisorgunit/service/printer       /xfn/_thisorgunit/service/printer
autofs  ignore,nest,dev=5540527 1225239827
-xfn/thisorgunit        /xfn/thisorgunit        autofs  ignore,nest,dev=5540528
1225239827
-xfn/thisorgunit/_service       /xfn/thisorgunit/_service       autofs  ignore,n
est,dev=5540529 1225239827
-xfn/thisorgunit/_service/printer       /xfn/thisorgunit/_service/printer
autofs  ignore,nest,dev=554052a 1225239827
-xfn/thisorgunit/service        /xfn/thisorgunit/service        autofs  ignore,n
est,dev=554052b 1225239827
-xfn/thisorgunit/service/printer        /xfn/thisorgunit/service/printer
autofs  ignore,nest,dev=554052c 1225239827
-xfn/_dns       /xfn/_dns       autofs  ignore,nest,dev=554052d 1225239827
-xfn/orgunit    /xfn/orgunit    autofs  ignore,nest,dev=554052e 1225239827
-xfn/org        /xfn/org        autofs  ignore,nest,dev=554052f 1225239827
-xfn/thisens    /xfn/thisens    autofs  ignore,nest,dev=5540530 1225239827
-xfn/_thisens   /xfn/_thisens   autofs  ignore,nest,dev=5540531 1225239827
-xfn/_x500      /xfn/_x500      autofs  ignore,nest,dev=5540532 1225239827
-xfn/_x500/CN=璧ゅ嘲鐢典笟灞

sun_sm

怎么没人回答啊，我还是顶一下吧！

yuhuohu

前不久刚有人问过 貌似是出在中文乱码部分

yuhuohu

search

df: a line in /etc/mnttab has too many fields

jimjiaozhu

你这个里面有autofs的内容，不奇怪呀。
如果不要看乱码的话，先把语言环境变量设置一下就好了

风之幻想

# df -h
df: a line in /etc/mnttab has too many fields
#
Luckily you could unmount the filesystem, but it was quite annoying to say the least. The resulting fix was really an exploration into bad interface design.

/etc/mnttab
This file has been around since the early days of Unix (at least as far back as SVR3). Each line is a whitespace-delimited set of fields, including special device, mount point, filesystem type, mount options, and mount time (see mnttab(4) for more information). Historically, this was a plain text file. This meant that the user programs mount(1M) and umount(1M) were responsible for making sure its contents were kept up to date. This could be very problematic: imagine what would happen if the program died partway through adding an entry, or root accidently removed an entry without actually unmounting it. Once the contents were corrupted, the admin usually had to resort to rebooting, rather than trying to guess what the proper contents. Not to mention it makes mounting filesystems from within the kernel unnecessarily complicated.

In Solaris 8, we solved part of the problem by creating the mntfs pseudo filesystem. From this point onward, /etc/mnttab was no longer a regular text file, but a mounted filesystem. The contents are generated on-the-fly from the kernel data structures. This means that the contents are always in sync with the kernel1, and that the user can't accidentally change the contents. However, we still had the problem that the mount points could not contain spaces, because space was a delimiter with special meaning.

getmntent() and friends
On top of this broken interface, a C API was developed that had even worse problems. Consider getmntent(3c):

int getmntent(FILE *fp, struct mnttab *mp);
There are several problems with this interface:

The user is responsible for opening and closing the file
There is only one mount state for the kernel; why should the user have to know that /etc/mnttab is the place where the entries are stored?

The first parameter is a FILE *
If you're developing a system interface, you should not enforce using the C stdio library. Every other system API takes a normal file descriptor instead./p>

The memory is allocated by the function on demand
This causes all sorts of problems, including making multithreaded difficult, and preventing the user from controlling the size of the buffer used to read in the data.

There is no relationship between the memory and the open file
Because of this, a lazy programmer can close the file after the last call to getmntent() while still using the memory, so it must be kept around indefinitely.

By now, it should be obvious that this was an ill-conceived API built on top of a broken interface. Off the top of my head, if I were to re-design these interfaces I would come up with something more like:

mnttab_t *mnttab_init(void);
int mnttab_get(mnttab_t *mnttab, struct mntent *ent, void *scratch, size_t scratchlen);
void mnttab_fini(mnttab_t *mnttab);
The solution
Once /etc/mnttab became a filesystem, we could add ioctl(2) calls to do whatever we wanted. Once we're in the kernel, we know exactly how long each field of the structure is. We create a set of NULL-terminated strings directly in user space, and simply return pointers to them. This was more complicated than it sounds for the reasons outlined above. We also had to maintain the ability to read the file directly. With this fix, all C consumers "just work". Scripted programs will still choke on a mnttab entry with spaces, but this is a minority by far.

Note that the files /etc/vfstab and /etc/dfs/sharetab still suffer from this problem. There has been some discussion about how to resolve these issues, with the new Service Management Facility being touted as a possible solution. And ZFF (Sun's next generation filesystem) is avoiding /etc/vfstab altogether.

sun_sm

不会是语言环境的关系，这是双机系统中的一台机器，另一台没有问题，好像和业务有关系！/lotus-set

jimjiaozhu

1） 去看看你的/etc/auto_master里面是不是有关于/xfn的东西。

[ 本帖最后由 jimjiaozhu 于 2009-1-14 11:06 编辑 ]

jimjiaozhu

语言是指你当前的终端的语言环境变量。
你执行 unset LANG就可以没有乱码了。