On Mon, 20 Jan 2003, David Schultz wrote:
First two entries clearly correspond to the missing file, which should
have been put in /home/lost+found. But, the poroblem is that no lost+found
directory was created, while it should (as fsck_ffs(8) says). I guess its
a bug, probably in the
On Wed, 22 Jan 2003 11:14:47 +0100 (CET), Jan Srzednicki
[EMAIL PROTECTED] said:
Would that be a big problem to allow some fsck option not to erase all
these softupdates-pending inodes, but to put them in lost+found as usual?
It certainly couldn't be done with the background fsck, because
On Wed, 22 Jan 2003, Garrett Wollman wrote:
Would that be a big problem to allow some fsck option not to erase all
these softupdates-pending inodes, but to put them in lost+found as usual?
It certainly couldn't be done with the background fsck, because
background fsck works on a snapshot
hi, there!
On Wed, Jan 22, 2003 at 07:18:44PM +0100, Jan Srzednicki wrote:
Would that be a big problem to allow some fsck option not to erase all
these softupdates-pending inodes, but to put them in lost+found as usual?
It certainly couldn't be done with the background fsck, because
Thus spake Garrett Wollman [EMAIL PROTECTED]:
On Wed, 22 Jan 2003 11:14:47 +0100 (CET), Jan Srzednicki
[EMAIL PROTECTED] said:
Would that be a big problem to allow some fsck option not to erase all
these softupdates-pending inodes, but to put them in lost+found as usual?
It certainly
At 12:53 AM +0600 1/23/03, Max Khon wrote:
On Wed, Jan 22, 2003 at 07:18:44PM +0100, Jan Srzednicki wrote:
Would that be a big problem to allow some fsck option not
to erase all these softupdates-pending inodes, but to put
them in lost+found as usual?
It certainly couldn't be
hi, there!
On Wed, Jan 22, 2003 at 02:43:37PM -0500, Garance A Drosihn wrote:
Would that be a big problem to allow some fsck option not
to erase all these softupdates-pending inodes, but to put
them in lost+found as usual?
It certainly couldn't be done with the
On Wed, 22 Jan 2003 11:32:12 -0800, David Schultz [EMAIL PROTECTED]
said:
Unfortunately, I think it is possible that the unreferenced inode
has not been initialized, even though it is allocated in the inode
bitmap, so you could potentially get random junk.
That is definitely true on UFS2,
Hello,
After building new world and installing new kernel, I rebooted my machine
to launch a new kernel. The system mysteriously failed to flush 22 disk
buffers, and after reboot fsck was launched. I have the following
partitions:
/ - UFS1
/usr - UFS2
/home - UFS1
This massive disk mangling
In the last episode (Jan 20), Jan Srzednicki said:
After building new world and installing new kernel, I rebooted my
machine to launch a new kernel. The system mysteriously failed to
flush 22 disk buffers, and after reboot fsck was launched.
[...]
This massive disk mangling occured on /usr,
Thus spake Jan Srzednicki [EMAIL PROTECTED]:
This massive disk mangling occured on /usr, but still, one file in /home
got lost - which happened to be quite important file. Background fsck
logged:
Jan 20 16:06:30 stronghold root: /dev/ad1s1d: UNREF FILE I=1723065
OWNER=winfried MODE=100644
:However, when you are saving a new version of an important file,
:you need to be careful that the new version (and its directory
:entry) hits the disk before the old one goes away. I know that vi
:saves files in a safe way, whereas ee and emacs do not. (Emacs
:introduces only a small race,
Thus spake Matthew Dillon [EMAIL PROTECTED]:
:However, when you are saving a new version of an important file,
:you need to be careful that the new version (and its directory
:entry) hits the disk before the old one goes away. I know that vi
:saves files in a safe way, whereas ee and emacs do
13 matches
Mail list logo
