rayan@ai.toronto.edu (Rayan Zachariassen) (12/25/88)
One of the filesystems on an ``unsupported'' machine lost all user files by (the equivalent of) rm -r done automatically by a script late at night. There was no other activity on the filesystem since the disaster, so I made an image copy and wrote a little program to fish out the textual data in the filesystem. So, I think, "hey, if all the inodes are still there they might have links to the data blocks of each file". Dragging out my inode-list walker routine, it turns out that all deallocated inodes have null mode, size, nlink, and db[] fields. The latter is the real killer, since without the disk block information, the old inode is useless. Knowing the size would be pretty helpful too, depending on the contents of db[]. I'd think that a zero nlink field should be enough to mark the inode as deallocated. I can imagine robustness (i.e. paranoid) reasons for zeroing out the other fields, but is it *really* necessary? If they aren't zeroed out, the information can be used to reconstruct removed files as long as the various blocks haven't been stomped on. Comments? I dimly recall some discussion about this a long time ago, does anyone remember the answers/conclusions? rayan
debra@alice.UUCP (Paul De Bra) (12/26/88)
In article <88Dec24.170417est.38019@neat.ai.toronto.edu> rayan@ai.toronto.edu (Rayan Zachariassen) writes: ]One of the filesystems on an ``unsupported'' machine lost all user files by ](the equivalent of) rm -r done automatically by a script late at night. ]... ]... Dragging out my ]inode-list walker routine, it turns out that all deallocated inodes have ]null mode, size, nlink, and db[] fields. The latter is the real killer, ]since without the disk block information, the old inode is useless. Knowing ]the size would be pretty helpful too, depending on the contents of db[]. ] ]I'd think that a zero nlink field should be enough to mark the inode as ]deallocated. I can imagine robustness (i.e. paranoid) reasons for zeroing ]out the other fields, but is it *really* necessary? If they aren't zeroed ]out, the information can be used to reconstruct removed files as long as the ]various blocks haven't been stomped on. ] I don't recall the previous discussion on this, but a zero nlink field only means that there are no directory entries pointing to this inode. It is still possible that some processes are accessing the file. Should the system crash, fsck will then find a linkless file and reconnect it in lost+found. The disk blocks occupied by the file are not added to the freelist when a file has no more links. All relevant fields of the inode must be zeroed for fsck to know that the file is really gone. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
rayan@ai.toronto.edu (Rayan Zachariassen) (12/26/88)
In article <8601@alice.UUCP> debra@alice.UUCP writes:
# I don't recall the previous discussion on this, but a zero nlink field only
# means that there are no directory entries pointing to this inode. It is still
# possible that some processes are accessing the file. Should the system
# crash, fsck will then find a linkless file and reconnect it in lost+found.
Should the system crash, the file is no longer needed because the processes
that referred to it aren't around any more. I thought about this a bit,
perhaps I don't believe in fsck as much as you do. Lost+found is usually
useless in my experience (of course if you don't have backups you're
grateful for *any* files to show up there, but they're usually not the
ones you care about...).
# The disk blocks occupied by the file are not added to the freelist when
# a file has no more links. All relevant fields of the inode must be zeroed
# for fsck to know that the file is really gone.
Right, what is the minimal set of relevant fields? Not adding the blocks
to the freelist on 0 link count is ok, it is done at last close. However
if you run fsck on a filesystem with such inodes, why should it find or
check those files? The whole point of having a file with no links is that
it will automatically disappear when the process dies (or is "unfindable"
by curious admins). It would be acceptable *in this context* to modify fsck
so it doesn't dig out such files.
Thanks.
rayanfriedl@vsi.COM (Stephen J. Friedl) (12/28/88)
In article <88Dec24.170417est.38019@neat.ai.toronto.edu>, rayan@ai.toronto.edu (Rayan Zachariassen) writes: > I'd think that a zero nlink field should be enough to mark the inode as > deallocated. This is not sufficient, because a file with zero links can still be used by the system (pipes, etc.). It seems to me that marking the mode field to zero is sufficient for this, as any other kind of file has at least one high-order bit set (even regular files). This is from <sys/stat.h> from System V: #define S_IFMT 0170000 /* type of file */ #define S_IFDIR 0040000 /* directory */ #define S_IFCHR 0020000 /* character special */ #define S_IFBLK 0060000 /* block special */ #define S_IFREG 0100000 /* regular */ #define S_IFIFO 0010000 /* fifo */ Comments? Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. ****Hi Mom!**** attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl -------Nancy Reagan on Usenix in San Diego: "Just say *go*"-------
breck@aimt.UU.NET (Robert Breckinridge Beatie) (01/05/89)
In article <981@vsi.COM>, friedl@vsi.COM (Stephen J. Friedl) writes: > > It seems to me that marking the mode field to zero is sufficient > for this, as any other kind of file has at least one high-order > bit set (even regular files). This is from <sys/stat.h> from > System V: > > #define S_IFMT 0170000 /* type of file */ > #define S_IFDIR 0040000 /* directory */ > #define S_IFCHR 0020000 /* character special */ > #define S_IFBLK 0060000 /* block special */ > #define S_IFREG 0100000 /* regular */ > #define S_IFIFO 0010000 /* fifo */ > > Comments? Not so much a comment as a question. I was looking into this question the other day and was not able to find a completely satisfactory answer. According to the SVID MKNOD(BA_OS) The mode of the new file is initialized from the argument _mode_. Where the value of _mode_ is interpreted as follows: 0170000 file type; one of the following: 0010000 FIFO-special 0020000 character-special 0040000 directory 0060000 block-special 0100000 or 000000 ordinary-file ^^^^^^ (Unfortunately, I wasn't able to find anything more useful.) Now it doesn't say anything about the mode parameter being placed directly into the di_mode field of the disk inode, but it doesn't say that it won't either. Well, I assumed that calling mknod with the mode field set to 000xxxx creates a file with mode equal to 010xxxx and that inodes whose di_mode field are zero are in fact unallocated since that seems to be the case on most systems I've checked. But is there any guarantee that on a "normal" system V file system this assumption won't blow up in my face. A pointer to the appropriate section in the SVID would be most reassuring. Assurances from a few wizards would be somewhat less reassuring, but would definitely be appreciated. -- Breck Beatie (408)748-8649 {uunet,ames!coherent}!aimt!breck OR breck@aimt.uu.net "Sloppy as hell Little Father. You've embarassed me no end."
guy@auspex.UUCP (Guy Harris) (01/05/89)
>A pointer to the appropriate section in the SVID would be most >reassuring. The SVID doesn't say anything about the format of the file system on disk; the 4.2BSD file system can be used in a SVID-compliant implementation (yes, 255-character file names and all), as can, say, the Apollo file system (they've said their SR10.1 release, or whatever the number is, passed the SVVS). As such, you're not likely to get any reassurances from the SVID about what a system'll do to the mode field of the inode... >Assurances from a few wizards would be somewhat less reassuring, but >would definitely be appreciated. ...however, since it says that either 0 or 0100000 represent plain files, and since in both the V7/S5 and 4.2BSD file systems 1) an all-zero mode field indicates an unused inode and 2) 0100000 in the upper 4 bits of the mode field indicate a plain file, non-buggy systems using either of those file systems will put 0100000 field of the inode if you do a "mknod" with either 0 or 0100000 in the upper 4 bits of the mode.
dtroup@carroll1.UUCP (Dave Troup) (01/06/89)
Actually, this should be an origional message, sorry 'bout that. Anyway, we have a 3B2-700 (AT&T) that is having a severe case of the crashes. In the crash log, some of the crashes are not even being logged. Q1. Is anyone else having these problems with their 3B2-700? Q2. Why would the crashes not be recorded? thank-you, dtroup@carroll1.UUCP David C. Troup