| Age | Commit message (Collapse) | Author |
|---|
|
due to ffs_sync not be able to sync some buffers here is another
instance of softdep code that must ensure proper syncing.
try harder to flush MKDIR_BODY dependancy if such still exists
during pagedep flush (that is by syncing first block of the dir).
pedro@ ok
|
|
the macro games in ufs_readwrite.c (LFS_READWRITE) now that
LFS has gone, make these functions ffs specific and move them
into ffs/ffs_vnops.c zapping ufs_readwrite.c in the process.
Also, remove lfs fields from the inode and ufsmount structs.
ok toby@,deraadt@,pedro@
testing and ok krw@
|
|
If an error occurs while writing a buffer, then the data will
not have hit the disk and the dependencies cannot be unrolled.
In this case, the system will mark the buffer as dirty again so
that the write can be retried in the future. When the write
succeeds or the system gives up on the buffer and marks it as
invalid (B_INVAL), the dependencies will be cleared.
pedro@ ok
|
|
|
|
|
|
|
|
|
|
Okay weingart@, "I'm game with putting my name on it" dlg@
|
|
functional change; pedro@ ok
|
|
|
|
softdep processing and temporarily create inconsistant
on-disk ffs state and as well abuse kmem.
pedro@ deraadt@ ok; tested by many
|
|
|
|
No binary change
|
|
compatible, adapted from FreeBSD, okay krw@
|
|
|
|
and mount error paths.
ok sturm@ pedro@
|
|
|
|
calling checkalias(), Daniel Junglas <dju@sysgo.com>, thanks.
|
|
will make pedro happy too (;
|
|
When the softupdates worklist gets too long, threads that attempt to
add more work are forced to process two worklist items first.
However, processing an item may generate additional work, causing the
unlucky thread to recursively process the worklist. Add a per-thread
flag to detect this situation and avoid the recursion. This should
fix the stack overflows that could occur while removing large
directory trees.
pedro@ tedu@ ok
|
|
requested by and ok pedro
|
|
and do not perform synchronous sync there is no wait requested by
skipping the drain_output() call. this fixes a problem where
update kthread would sleep forever on some vnode since work is created
faster than it can be flushed. pedro@ ok; tested by many
|
|
pedro@ ok; tested by many
|
|
the softdep stubs which get optimized out when DOINGSOFTDEP evaluates to zero
at compile time and thus are never ever invoked; ok deraadt@
|
|
backing dinode, in which case we just want to recycle the vnode.
Fixes a crash reported by reyk@, okay krw@, mickey@ and pat@.
|
|
and remove the corresponding panics in low level code.
ok pedro@ weingart@
|
|
ok tedu, pedro
|
|
After a rmdir()ed directory has been truncated, force an update of
the directory's inode after queuing the dirrem that will decrement
the parent directory's link count. This will force the update of
the parent directory's actual link to actually be scheduled. Without
this change the parent directory's actual link count would not be
updated until ufs_inactive() cleared the inode of the newly removed
directory, which might be deferred indefinitely. ufs_inactive()
will not be called as long as any process holds a reference to the
removed directory, and ufs_inactive() will not clear the inode if
the link count is non-zero, which could be the result of an earlier
system crash.
If a background fsck is run before the update of the parent directory's
actual link count has been performed, or at least scheduled by
putting the dirrem on the leaf directory's inodedep id_bufwait list,
fsck will corrupt the file system by decrementing the parent
directory's effective link count, which was previously correct
because it already took the removal of the leaf directory into
account, and setting the actual link count to the same value as the
effective link count after the dangling, removed, leaf directory
has been removed. This happens because fsck acts based on the
actual link count, which will be too high when fsck creates the
file system snapshot that it references.
This change has the fortunate side effect of more quickly cleaning
up the large number dirrem structures that linger for an extended
time after the removal of a large directory tree. It also fixes a
potential problem with the shutdown of the syncer thread timing out
if the system is rebooted immediately after removing a large directory
tree.
|
|
|
|
stuff that relies on ffs_update() to flush an inode will fail.
Fixes PR 4997, okay tedu@
|
|
used and will never be used this way in VFS
requested by and ok pedro, ok krw, biorn
|
|
freebsd's mutexes served here, but they are only for smp protection.
the code is careful not to block and needs no rwlocks.
ok pedro and an assortment of testers
|
|
|
|
kernels and old tools are safe.
i'm leaving in the "updated" flag, so that fsck will continue to remove
it from filesystems. the kernel no longer attempts to upgrade
superblocks and will use the old format.
post-mortem discussions have concluded that maybe jamming ffs2 fields
into random locations in the superblock is asking for trouble, and we
need to talk about this some more. my bad for not thinking fast enough.
|
|
|
|
|
|
|
|
|
|
|
|
- Insert some comments and space the code to improve readability
- Make sure the inode's gen number is always positive (from NetBSD)
|
|
|
|
|
|
couple of new fields needed by FFS2, no functional change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
