Remove /^\.\\"\s*\$FreeBSD\$$\n/

There are FAT12 and FAT16 file systems, but FAT13 of was an
unintentional invention of mine ...

Reported by:	Ravi Pokala <rpokala@freebsd.org>
MFC after:	1 month

This update implements tallying of free directory entries during
create, delete,	or rename operations on FAT12 and FAT16 file systems.

Prior to this change, the total number of root directory entries
was reported as number of inodes, but 0 as the number of free
inodes, causing system health monitoring software to warn about
a suspected disk full issue.

The FAT12 and FAT16 file systems provide a limited number of
root directory entries, e.g. 512 on typical hard disk formats.
The valid range of values is 1 to 65535, but the msdosfs code
will effectively round up "odd" values to the next multiple of 16
(e.g. 513 would allow for 528 root directory entries).

This update implements tracking of directory entries during create,
delete, or rename operations, with initial values determined by
scanning the directory when the file system is mounted.

Total and free directory entries are reported in the f_files and
f_ffree elements of struct statfs, despite differences in semantics
of these values:

- There is no limit on the number of files and directories that can
  be created on a FAT file system. Only the root directory of FAT12
  and FAT16 file systems is limited, any number of files can still be
  created in sub-directories, even when 0 free "inodes" are reported.

- A single file can require 1 to 21 directory entries, depending on
  the character set, structure, and length of the name. The DOS 8.3
  style file name takes up 1 entry, and if the name does not comply
  with the syntax of a DOS 8.3 file name, 1 additional entry is used
  for each 13 characters of the file name. Since all these entries
  have to be contiguous, it is possible that a file or directory with
  a long name can not be created, despite a sufficient total number of
  free directory entries.

- Renaming a file can require more directory entries than currently
  allocated to store its long name, which may prevent an in-place
  update of the name if more entries are needed. This may cause a
  rename operation to fail if no contiguous range of free entries for
  the new name can be found.

- The volume label is stored in a directory entry. An empty FAT file
  system with a volume label will therefore show 1 used "inode" in
  df.

- The perceentage of free inodes shown in df or monitoring tools does
  only represent the state of the root directory of a FAT12 or FAT16
  file system. Neither does a reported value of 0% free inodes does
  prevent files from being created in sub-directories, nor does a
  value of 50% free inodes guarantee that even a single file with
  a "long" name can be created in the root directory (if every other
  directory entry is occupied and there are no 2 contiguous entries).

The statfs(2) and df(1) man pages have been updated with a notice
regarding the possibly different semantics of values reported as
total and free inodes for non-Unix file systems.

PR:		270053
Reported by:	Ben Woods <woodsb02@freebsd.org>
Approved by:	mckusick
MFC after:	1 month
Differential Revision:	https://reviews.freebsd.org/D38987

EINTEGRITY was previously documented as a UFS-specific error for
mount(2).  This documents EINTEGRITY as a filesystem-independent error
that may be reported by the backing store of a filesystem.

While here, document EIO as a filesystem-independent error for both
mount(2) and posix_fadvise(2).  EIO was previously only documented for
UFS for mount(2).

Reviewed by:	mckusick
Suggested by:	mckusick
MFC after:	2 weeks
Sponsored by:	Chelsio Communications
Differential Revision:	https://reviews.freebsd.org/D24168

Sponsored by: Netflix

Extend the ino_t, dev_t, nlink_t types to 64-bit ints.  Modify
struct dirent layout to add d_off, increase the size of d_fileno
to 64-bits, increase the size of d_namlen to 16-bits, and change
the required alignment.  Increase struct statfs f_mntfromname[] and
f_mntonname[] array length MNAMELEN to 1024.

ABI breakage is mitigated by providing compatibility using versioned
symbols, ingenious use of the existing padding in structures, and
by employing other tricks.  Unfortunately, not everything can be
fixed, especially outside the base system.  For instance, third-party
APIs which pass struct stat around are broken in backward and
forward incompatible ways.

Kinfo sysctl MIBs ABI is changed in backward-compatible way, but
there is no general mechanism to handle other sysctl MIBS which
return structures where the layout has changed. It was considered
that the breakage is either in the management interfaces, where we
usually allow ABI slip, or is not important.

Struct xvnode changed layout, no compat shims are provided.

For struct xtty, dev_t tty device member was reduced to uint32_t.
It was decided that keeping ABI compat in this case is more useful
than reporting 64-bit dev_t, for the sake of pstat.

Update note: strictly follow the instructions in UPDATING.  Build
and install the new kernel with COMPAT_FREEBSD11 option enabled,
then reboot, and only then install new world.

Credits: The 64-bit inode project, also known as ino64, started life
many years ago as a project by Gleb Kurtsou (gleb).  Kirk McKusick
(mckusick) then picked up and updated the patch, and acted as a
flag-waver.  Feedback, suggestions, and discussions were carried
by Ed Maste (emaste), John Baldwin (jhb), Jilles Tjoelker (jilles),
and Rick Macklem (rmacklem).  Kris Moore (kris) performed an initial
ports investigation followed by an exp-run by Antoine Brodin (antoine).
Essential and all-embracing testing was done by Peter Holm (pho).
The heavy lifting of coordinating all these efforts and bringing the
project to completion were done by Konstantin Belousov (kib).

Sponsored by:	The FreeBSD Foundation (emaste, kib)
Differential revision:	https://reviews.freebsd.org/D10439

Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.

Submitted by:	Jan Schaumann <jschauma@stevens.edu>
Pull Request:	https://github.com/freebsd/freebsd/pull/96

clause.

# If I've done so improperly on a file, please let me know.

Pointed out by: Antony Curtis <antony@mysql.com>