This will be unflipped when the format is finalized - right now I
still have pending changes to the superblock in mind (to reduce the
number of redundant fields) so anything created now is not future-
proof. However, the code's also nearing being ready for testing; so
I'm doing this before turning it on as a precaution.
The vnodes are always referenced on entry.
If we changed ulfs_remove() and ulfs_rmdir() to return the locked dvp
the vnodes were always locked on entry.
Remove an outdated comment from lfs_reserveavail(), unlocking/relocking
the vnode was removed in rev 1.49.
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.
blocks portion of the segment summary.
A segment summary block begins with a header (SEGSUM); the rest of the
block contains FINFO structures describing file blocks growing upward
from the bottom (after the header), and IINFO structures describing
inode blocks grown downward from the end of the block. (When they meet
the segment is full regardless of how many blocks might be left.)
IINFO contains just a block number, and until now this information was
handled by just using uint32_t*; switching to a structure will make
the code a lot easier to read, and also make it easier to have 32-bit
and 64-bit versions without making a mess.
This commit just adds the structures and accessors; they'll be
deployed into the code in subsequent commits.
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.
For now, move one copy of the code that allocates and fills in a
temporary struct lfs_direct to the top of ulfs_direnter; but it should
go away shortly.
(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.)
number it was supposed to be allocating with the head of the inode
freelist, then applying the wrong test to that result. Net result:
unless the freelist was empty (in which case it would always fail),
it would in general drop a bunch of entries from the freelist.
This code seems to have been broken when the first version of lfsv2
was imported onto the perseant-lfsv2 branch in -r1.47.2.1, and
remained broken since, in spite of having been moved to lfs_rfw.c and
back and rearranged quite a bit in the meantime.
Sigh.
Found by Coverity in a rather confusing way as CID 1316545.
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.)
other lfs64 on-disk inode numbers; I've been doing that since this is
a new format and we may as well take the opportunity. This does assume
that more than 4 billion files on a single volume becomes desirable;
but for an average file size of 10K all that takes is a 40 TB volume,
and it's not that hard to make one of those these days if you want to
badly enough.
pgoyette