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.)
