<
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, which I had forgotten. UFS2 inodes
are only initialized when they
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 b
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
Thus spake Garrett Wollman <[EMAIL PROTECTED]>:
> <<[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, becau
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, b
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 snap
< 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
background fsck works on a snapshot and not the running filesystem;
thus, it
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 t
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 ema
: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, thoug
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=1
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
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 occu
13 matches
Mail list logo
