Re: background fsck did not create lost+found
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 background fsck code. Still, is there any way to reclaim the file now, besides running strings(1) on the whole partition? Consider what happens when you remove a large directory tree. Thousands of directory entries may be removed, but in the softupdates case, the inodes will stick around a bit longer. The same also applies to files that have been intentionally unlinked but are still open. To avoid a syndrome where all these thousands of files end up in lost+found after a crash or power failure, fsck just removes them on softupdates-enabled filesystems. 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? The default behaviour is unchanged, yet there is a way to reclaim lost files. -- -- wrzask --= v =-- Winfried --=-- GG# 3838383 --=-- JS500-RIPE -- -- [EMAIL PROTECTED] --- [EMAIL PROTECTED] --===-- http://violent.dream.vg/ --- --= Ride the wild wind - push the envelope, don't sit on the fence, --- -- Ride the wild wind - live life on the razor's edge! =-- Queen -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
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 background fsck works on a snapshot and not the running filesystem; thus, it cannot make any allocations -- it can only deallocate things. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
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 and not the running filesystem; thus, it cannot make any allocations -- it can only deallocate things. Still, in case you know some of your important files can be lost, you can boot the system to single user and run foreground fsck. -- -- wrzask --= v =-- Winfried --=-- GG# 3838383 --=-- JS500-RIPE -- -- [EMAIL PROTECTED] --- [EMAIL PROTECTED] --===-- http://violent.dream.vg/ --- --= Ride the wild wind - push the envelope, don't sit on the fence, --- -- Ride the wild wind - live life on the razor's edge! =-- Queen -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
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 background fsck works on a snapshot and not the running filesystem; thus, it cannot make any allocations -- it can only deallocate things. Still, in case you know some of your important files can be lost, you can boot the system to single user and run foreground fsck. this is not an option if the system was rebooted because of power loss or kernel panic /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
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 couldn't be done with the background fsck, because background fsck works on a snapshot and not the running filesystem; thus, it cannot make any allocations -- it can only deallocate things. Actually, that should work just fine. When background fsck notices an unreferenced inode in the snapshot, it could create a file in the underlying filesystem. The easy way to do this is to copy the data with the standard open(2)/write(2)/close(2) interfaces. After the copy, the original data blocks are deallocated as usual. A more efficient implementation might require a special kernel interface that creates a directory entry, given an inode number and path. 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. Such a feature sounds reasonable, although I'm not sure how useful it would really be. If you have software that introduces a race window where you can lose data because it does updates incorrectly, hacking the operating system to make the race window slightly smaller is not the best solution. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
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 done with the background fsck, because background fsck works on a snapshot and not the running filesystem; thus, it cannot make any allocations -- it can only deallocate things. Still, in case you know some of your important files can be lost, you can boot the system to single user and run foreground fsck. this is not an option if the system was rebooted because of power loss or kernel panic Can't you just set the rc.conf option to not-do the background fsck? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
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 background fsck, because background fsck works on a snapshot and not the running filesystem; thus, it cannot make any allocations -- it can only deallocate things. Still, in case you know some of your important files can be lost, you can boot the system to single user and run foreground fsck. this is not an option if the system was rebooted because of power loss or kernel panic Can't you just set the rc.conf option to not-do the background fsck? I can but the whole purpose of background fsck (faster startup times) will be lost. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
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, which I had forgotten. UFS2 inodes are only initialized when they are used. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
background fsck did not create lost+found
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 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 Jan 20 16:06:30 stronghold root: /dev/ad1s1d: SIZE=23397 MTIME=Jan 20 15:57 2003 (CLEARED) Jan 20 16:06:30 stronghold root: /dev/ad1s1d: Reclaimed: 0 directories, 8 files, 16439 fragments Jan 20 16:06:30 stronghold root: /dev/ad1s1d: 33802 files, 13109700 used, 6310697 free (11577 frags, 787390 blocks, 0.1% fragmentation) 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 background fsck code. Still, is there any way to reclaim the file now, besides running strings(1) on the whole partition? -- -- wrzask --= v =-- Winfried --=-- GG# 3838383 --=-- JS500-RIPE -- -- [EMAIL PROTECTED] --- [EMAIL PROTECTED] --===-- http://violent.dream.vg/ --- --= Ride the wild wind - push the envelope, don't sit on the fence, --- -- Ride the wild wind - live life on the razor's edge! =-- Queen -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
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, 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 Jan 20 16:06:30 stronghold root: /dev/ad1s1d: SIZE=23397 MTIME=Jan 20 15:57 2003 (CLEARED) Jan 20 16:06:30 stronghold root: /dev/ad1s1d: Reclaimed: 0 directories, 8 files, 16439 fragments Jan 20 16:06:30 stronghold root: /dev/ad1s1d: 33802 files, 13109700 used, 6310697 free (11577 frags, 787390 blocks, 0.1% fragmentation) 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 background fsck code. Still, is there any way to reclaim the file now, besides running strings(1) on the whole partition? It's not a bug. Softupdates works by guaranteeing that the only things that a background fsck needs to do are reduce link counts, clear inodes, and fix free-space bitmaps. Bgfsck will clear a file's space rather than put it in lost+found. This means that if you delete a file, immediately create a new one with the same name, and then reboot within 30 seconds, both files will be gone. You can minimize the risk by lowering the kern.metadelay, kern.dirdelay, and kern.filedelay sysctl values, but the lower you go, the less benefit you get. String'ing the raw partition is probably your best bet for recovering the data. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
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 Jan 20 16:06:30 stronghold root: /dev/ad1s1d: SIZE=23397 MTIME=Jan 20 15:57 2003 (CLEARED) Jan 20 16:06:30 stronghold root: /dev/ad1s1d: Reclaimed: 0 directories, 8 files, 16439 fragments Jan 20 16:06:30 stronghold root: /dev/ad1s1d: 33802 files, 13109700 used, 6310697 free (11577 frags, 787390 blocks, 0.1% fragmentation) 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 background fsck code. Still, is there any way to reclaim the file now, besides running strings(1) on the whole partition? Consider what happens when you remove a large directory tree. Thousands of directory entries may be removed, but in the softupdates case, the inodes will stick around a bit longer. The same also applies to files that have been intentionally unlinked but are still open. To avoid a syndrome where all these thousands of files end up in lost+found after a crash or power failure, fsck just removes them on softupdates-enabled filesystems. Unfortunately, this means that a newly-created file that has an inode but no directory entry will also be cleared. In some sense, this race is equivalent to the situation where something went wrong before the inode could be written. 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, though.) Also, mv will DTRT only if the source and destination files live on the same filesystem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
: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, though.) Also, mv will DTRT only if :the source and destination files live on the same filesystem. : I think you have that reversed. vi just overwrites the destination file (O_CREAT|O_TRUNC, try ktrace'ing a vi session and you will see). I believe emacs defaults to a mode where it creates a new file and renames it over the original. This means that there is a period of time where a crash may result in the loss of the file if the vi session cannot be recovered (with vi -r) after the fact. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
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 not. (Emacs
:introduces only a small race, though.) Also, mv will DTRT only if
:the source and destination files live on the same filesystem.
:
I think you have that reversed. vi just overwrites the destination
file (O_CREAT|O_TRUNC, try ktrace'ing a vi session and you will see).
I believe emacs defaults to a mode where it creates a new file and
renames it over the original.
This means that there is a period of time where a crash may result in
the loss of the file if the vi session cannot be recovered (with vi -r)
after the fact.
vi writes and fsyncs a recovery file when it opens a file for
editing, and it fsyncs the real file before removing the recovery
file. (I don't know how reliable vi's recovery mechanism is
because I don't use vi, but at least it's ensuring that the
recovery file is written to disk when it should be.)
In Emacs, if 'make-backup-files' is non-nil (the default), the
original file ${FILE} is renamed to ${FILE}~. Then it writes out
and fsyncs a new file, which is perfectly safe. If
'make-backup-files' is nil, emacs simply omits the renaming part,
unsafely overwriting the original file. The behavior in the
latter case appears to be a bug, or at least an undocumented
feature. Emacs even causes data loss in this case when the disk
fills up! It needs to either do an fsync/rename or write and
fsync a backup file for the duration of the save.
Lastly, with ee, there's no backup file and no fsync.
Some ktrace snippets are below.
3662 vi CALL open(0x808e260,0x2,0x180)
3662 vi NAMI /var/tmp/vi.recover/vi.HjDlgO
3662 vi RET open 4
...
3662 vi CALL write(0x4,0x809a01c,0x400)
3662 vi GIO fd 4 wrote 1024 bytes
[...]old contents[...]
...
3662 vi CALL fsync(0x4)
3662 vi RET fsync 0
...
[I edit the file from old contents to new contents]
...
3662 vi CALL open(0x8095140,0x601,0x1b6)
3662 vi NAMI foo
3662 vi RET open 7
...
3662 vi CALL write(0x7,0x80bb000,0xd)
3662 vi GIO fd 7 wrote 13 bytes
new contents
3662 vi RET write 13/0xd
...
3662 vi CALL fsync(0x7)
3662 vi RET fsync 0
3662 vi CALL close(0x7)
3662 vi RET close 0
...
3662 vi CALL lseek(0x4,0,0x400,0,0)
3662 vi RET lseek 1024/0x400
3662 vi CALL write(0x4,0x809a01c,0x400)
3662 vi GIO fd 4 wrote 1024 bytes
[...]new contents[...]
...
3662 vi CALL fsync(0x4)
3662 vi RET fsync 0
[The following bit only happens if make-backup-files is non-nil]
3799 emacsCALL rename(0x848c328,0x848fba8)
3799 emacsNAMI /home/test/foo
3799 emacsNAMI /home/test/foo~
3799 emacsRET rename 0
...
[This part happens unconditionally]
3799 emacsCALL open(0x848c328,0x601,0x1b6)
3799 emacsNAMI /home/test/foo
3799 emacsRET open 3
3799 emacsCALL write(0x3,0xbfbfae24,0x3)
3799 emacsGIO fd 3 wrote 3 bytes
new
3799 emacsRET write 3
3799 emacsCALL write(0x3,0xbfbfae24,0x9)
3799 emacsGIO fd 3 wrote 9 bytes
contents
3799 emacsRET write 9
3799 emacsCALL fsync(0x3)
3799 emacsRET fsync 0
3799 emacsCALL close(0x3)
3799 emacsRET close 0
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
