Linux-kernel mailing list archive 1999-34,: Re: [PATCH] robust ext2fs against failure

# Re: [PATCH] robust ext2fs against failure

Kazuto MIYOSHI (kaz@earth.email.ne.jp)
Thu, 26 Aug 1999 00:51:44 +0900

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Benno Senoner: "Re: mmap() better than read() fro streaming, Was: Re: Streaming disk I/O kills file buffering and makes Linux unusable"
- Previous message: david parsons: "[PATCH] 2.3.15 fancy memory detection patch, reworked"
- In reply to: Theodore Y. Ts'o: "Re: [PATCH] robust ext2fs against failure"

"Theodore Y. Ts'o" <tytso@mit.edu> writes:

tytso> I can not say positively, but perhaps it is because some new directory
tytso> entry which contains garbage (on disk) was allocated for some new
tytso> file. If the garbage data points NTFS makefile accidentally and system
tytso> crashes before the directory entry is written back, new file and NTFS
tytso> makefile are doubly hard-linked. Someone writes binary data to the new
tytso> file, NTFS makefile would be also altered...
tytso>
tytso> If you ran e2fsck after the each system crash, it would have detected
tytso> any doubly allocated files and offered to clone the data blocks to avoid
tytso> this problem.

Probably my example is not so clear/adequate...

The situation which I mean is that one new directory entry is
allocated to point a newly-created memory inode, but corresponding
disk inode still contains GARBAGE then:

dir-entry inode

fs/ntfs/ ---------- Makefile
:
......:
:
/tmp/ ------+--> tmp990825

---> memory inode
.... garbage on the disk (of cource, overwritten in future...)

If system crashes before the memory INODE is written back over the
garbage, it causes doubly-linked file.

replicate files (inodes) pointed from two separate directory
entries. E2fsck just adds 1 reference count to the inode.

Thanks.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Benno Senoner: "Re: mmap() better than read() fro streaming, Was: Re: Streaming disk I/O kills file buffering and makes Linux unusable"
- Previous message: david parsons: "[PATCH] 2.3.15 fancy memory detection patch, reworked"
- In reply to: Theodore Y. Ts'o: "Re: [PATCH] robust ext2fs against failure"