Julian Elischer [1] and the Mach 2.5 Installation notes [2].
I was unable to pin point the exact version of Mach the fdisk utility appeared
as I didn't find documentation older than version 2.5 & no source code or repo
history. fdisk utility appears as a separate utility[3] in v2.5. Due to this,
I've avoided stating the exact version fdisk first appeared in Mach.
- Make correction pointed by textproc/igor
- Bump date
[1] https://groups.google.com/forum/#!searchin/comp.unix.bsd/14-Dec-89$20Robert$20Baron$20(rvb)$20at$20Carnegie-Mellon$20University%7Csort:relevance/comp.unix.bsd/Hhi45vAHxDg
[2] ftp://ftp.mcs.vuw.ac.nz/doc/misc/mach-i386-doc/i386_install.ps
[3] ftp://ftp.mcs.vuw.ac.nz/doc/misc/mach-i386-doc/i386_manpages.ps
e2di_size_high; even Linux ext2 filesystem code actually uses it
unconditionally this way and ext4 code finally also calls it that way
in their struct definition too; if there was any trace of this for other
purpose it's long gone
sysctl variable using ?= fails with EPERM, don't print an error
message.
Ideally setting a sysctl to the same value it already has should also
not fail regardless of permissions, but this would need to be done in
the kernel.
so they can't illegally reenter libc.
Fixes the problem Greg A. Woods describes in PR 51267, which might or
might not be the original submitter's problem.
The superblock field that distinguishes between 4.2BSD and 4.4BSD
inodes is really only relevant on a UFS1 file system. Make sure that
it is a UFS1 fs before using fs_old_inodefmt.
Note that the NetBSD newfs and mkfs utilities initialize fs_old_inodefmt
even for UFS2, so problems were apparent only on file systems created
by other operating systems, for example, FreeBSD.
distinct and allowing this makes certain useful tasks possible, such as
fixing an unpopulated /dev while a tmpfs is mounted over it.
However, require the paths to be different, as mounting a path directly over
itself has the side effect of causing any other mount points within that path
to no longer be accessible, and is difficult to unmount when done on /.
(e.g. umount_ffs, umount_nfs, etc.) exec it instead of calling
unmount(2).
Closes PR 698.
Note that the original plan for the PR also involved adding a generic
facility to store an alternate FS type name in the kernel to use when
unmounting. This was intended to support filesystems implemented as
loopback nfs servers, where the visible mount would be of type "nfs"
pointing at localhost; in that case one would want to be able to
provide an additional string in order to run an unmount program that
would both remove that mount and also shut down the loopback nfs
server daemon.
However, in the 21+ years since the PR was filed, loopback nfs servers
have gone out of favor (for good reasons) so I don't see any need to
worry about this case at present, especially since the PR has been
hanging around this long anyway. (If anyone still has a loopback nfs
server that they want to use a custom unmount program with, file a new
PR and assign it to me and I'll deal with it specifically in the nfs
mount args structure, which unmount already knows how to retrieve and
examine.)
It is my understanding that filesystems implemented with fuse (which
has displaced the loopback nfs server model) can already set the FS
type field so no further work is needed to allow them to use a custom
unmount program. If this is not the case, please let me know and I'll
attend to it.
There is no longer any need that I see to provide a general facility
for storing an alternate filesystem type name.
(One might also ask whether there's any real need for this
functionality at all any more; this is a fair question, but (a) the
change is small and (b) there are certainly cases when doing FS
research where you want a custom unmount program; been there & done
that.)
- debug log is now using syslog
- seperate options for log level and foreground mode
- writes a pidfile so that /etc/rc.d/iscsid works
Now links with libutil for pidfile(), the functions login() and logout()
needed to be renamed to avoid a conflict.
- drops the nothreads option
- handles signals to shut down gracefully
- the driver may also shut down the daemon when it terminates
Currently this cannot work as the driver can only terminate when
the daemon has closed the driver file handle.
micron's "TN-FD-33: M510DC SSD SMART Implementation Introduction"
document.
these two values can be used to calculate the write amplication
factor:
WAF = ( A247 + A248 ) / A247
By this change, nexthop caches (IP-MAC address pair) are not stored
in the routing table anymore. Instead nexthop caches are stored in
each network interface; we already have lltable/llentry data structure
for this purpose. This change also obsoletes the concept of cloning/cloned
routes. Cloned routes no longer exist while cloning routes still exist
with renamed to connected routes.
Noticeable changes are:
- Nexthop caches aren't listed in route show/netstat -r
- sysctl(NET_RT_DUMP) doesn't return them
- If RTF_LLDATA is specified, it returns nexthop caches
- Several definitions of routing flags and messages are removed
- RTF_CLONING, RTF_XRESOLVE, RTF_LLINFO, RTF_CLONED and RTM_RESOLVE
- RTF_CONNECTED is added
- It has the same value of RTF_CLONING for backward compatibility
- route's -xresolve, -[no]cloned and -llinfo options are removed
- -[no]cloning remains because it seems there are users
- -[no]connected is introduced and recommended
to be used instead of -[no]cloning
- route show/netstat -r drops some flags
- 'L' and 'c' are not seen anymore
- 'C' now indicates a connected route
- Gateway value of a route of an interface address is now not
a L2 address but "link#N" like a connected (cloning) route
- Proxy ARP: "arp -s ... pub" doesn't create a route
You can know details of behavior changes by seeing diffs under tests/.
Proposed on tech-net and tech-kern:
http://mail-index.netbsd.org/tech-net/2016/03/11/msg005701.html
2nd packet and subsequent packets are sent based on SIGALRM and
it depends on poll(2) returns with EINTR by the signal. However,
currently poll is rump-ified while signals aren't so the signal
doesn't wake up poll and ping6 doesn't work expectedly.
Rump-ifying signals is unsure (nobody does it for now) and the
combination use of signals and poll makes the logic a bit complex.
So let's fix the defect by stopping using signals for packet
transmissions. The new logic is derived from ping(8).
Bonus: ping6 -i 0.01 works as we expect now while the original
didn't work enough fast.
It exited with status 0 when at least one packet was received
and timed out. However, when we specify -c N (while N > 0),
we expect that it fails if it times out before all sent requests
are replied.
For now at least it will refuse to touch it though as it needs to be
taught more abstraction about directory entries; currently it blindly
uses struct direct from ffs and will croak on the lfs64 64-bit inode
numbers.
To create an lfs64 volume, use -w 64. You can also force a 32-bit
volume with -w 32, but this will fail on devices thta are too large.
lfs64 is the default for devices > 1TB. (1TB rather than 2TB because
daddr_t is signed and negative block numbers can cause interesting
complications.)
For now print a warning that the lfs64 format isn't finalized, because
it isn't. For now any lfs64 use should be limited to test data,
benchmarking, and so forth.
add and remove loops. now when you add a new swap file and run
"swapctl -A" it won't give up after the existing one gives EBUSY
and move on to the rest.
so widen it to 'long long'. pass2 uses it for the number of entries in
a directory (IIUC) which does not need to be wider than int, but for
now let's not try to split into two fields. FUTURE...
This is always uint32_t, but having a name for it both makes things
clearer and avoids confusion about whether it should be 32 or 64 bit.
Note: deployed in only one place (that was erroneously tagged
ondisk32) so far.
- compute the maximum file size using LFS_BLKPTRSIZE()
- use the new IINFO in pass 6 instead of uint32_t pointers
- use accessors to read and write indirect blocks
The LFS64 directory entry has a 64-bit inode number. This is stored as
two 32-bit values to avoid inducing 64-bit alignment requirements.
The exposed type for manipulating directory entries is now
LFS_DIRHEADER, following the same convention as e.g. IFILE and SEGUSE.
(But with LFS_ on it, because.)
Also, it turns out that dirhash needs a compile-time-constant version
of LFS_DIRECTSIZ(LFS_MAXNAMLEN+1), independent of 64-vs-32, so create
LFS_MAXDIRENTRYSIZE for this. Sigh.
it in place of (variously) memcpy and strlcpy. (The latter isn't even
correct; was probably changed blindly from strncpy at some point.)
The new function zeroes the padding in the directory entry instead of
leaving trash behind.
0 instead of size LFS_MAXNAMLEN+1, and preparatory to having accessor
functions for d_name. In particular, don't create prototype entries
and copy them, and access the name field only for directory structures
that are in buffers with space for the name to exist.
(lfs_dirheader)
Take the opportunity to improve the directory generation code in
make_lfs.c. (Everything else was unaffected by virtue of using
accessor functions.)
getaddrinfo and if_nametoindex are newly added to interpret interface names
in IPv6 link-local addresses. if_nametoindex looks not used in rump.route,
but it is needed because it is used indirectly from getaddrinfo.
From s-yamaguchi@IIJ
Therefore, storing the value in the superblock and reading it out
again is silly and offers the opportunity for it to become corrupted.
So, don't do that (most of the code already didn't) and use the
existing constant instead. Initialize new 32-bit superblocks with
the value for the sake of old userland programs, but don't keep the
value in the 64-bit superblock at all.
(approved by Margo Seltzer)
Reasoning as before.
Note that I am not going through and checking for 64->32 truncations
in inode numbers; I'm sure there are quite a few, but that's a project
for later.
This prevents regressions in the ulfs code when switching to the new
accessors. Note that while adding byteswapping to the other accessors
is straightforward, I haven't done it yet; and that also is not enough
to make LFS_EI work, because there are places lying around that bypass
the accessors for one reason and another and all of them need to be
updated. That is going to have to wait for a later day as LFS_EI is
not on the critical path right now.
(Mostly.)
The ufs-derived ones are fake structure member macros, which are gross
and not very safe. Also, it seems that a lot of places in the lfs code
were using the ffsv1 branch of them unconditionally, and this way it's
guaranteed all those places have been updated.
Found while doing this: for non-devices, have getattr produce NODEV
in the rdev field instead of leaking the address of the first direct
block.
(This part changes the native lfs code; the ufs-derived code already
has 64 vs. 32 logic, but as aspects of it are unsafe, and don't
entirely interoperate cleanly with the lfs 64/32 stuff, pass 2 will be
rehashing that.)
Add pieces of support for using both superblock types where
convenient, and specifically to the superblock accessors, but don't
actually enable it anywhere.
First substantive step on PR 50000.
