Re: [PLUG] Orphaned inodes
Unless I'm mistaken, EXT3 and 4 will always report orphaned inodes after a crash (if they occur). It's just part of the logging like frank mentioned. However, I do remember instances back when I was using EXT3 that the journal would be replayed after normal cold boots. It was also much slower than EXT4 which made it look scarier than it really is. On Wed, Jul 3, 2019 at 8:28 AM Rich Shepard wrote: > > On Wed, 3 Jul 2019, Frank Filz wrote: > > > Other than a crash or a code bug, I can't think of any reason. > > Frank, > > Me, neither. > > > e2fsck does the journal replay after a crash, so it's reporting orphaned > > inodes may just be part of journal replay. > > Yes, and this is why I asked the question. > > Thanks much, > > Rich > ___ > PLUG mailing list > PLUG@pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Orphaned inodes
On Wed, 3 Jul 2019, Frank Filz wrote: Other than a crash or a code bug, I can't think of any reason. Frank, Me, neither. e2fsck does the journal replay after a crash, so it's reporting orphaned inodes may just be part of journal replay. Yes, and this is why I asked the question. Thanks much, Rich ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Orphaned inodes
> > Hmm, the crash must be causing open but unlinked inodes to be lost, > > Frank, > > I assume this is the case. When the system reboots (and it's been >200 days) the > kernel forces a filesystem check (it's ext3 on this host). > > The reason I asked is curiosity what, other than a system crash, could cause > inodes to become orphaned. Other than a crash or a code bug, I can't think of any reason. Even if a process that holds an open file descriptor on an unlinked file crashes, the kernel will still clean up all the open file descriptors for that process, which will prompt releasing any inodes with a link count of 0 that now no longer have any open file descriptors anchoring them. EXT3 journaling should handle all the system crash cases. Ok, it maybe doesn't handle all crashes - I was just reading up on it... e2fsck does the journal replay after a crash, so it's reporting orphaned inodes may just be part of journal replay. Frank ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Orphaned inodes
On Fri, 28 Jun 2019, Frank Filz wrote: Hmm, the crash must be causing open but unlinked inodes to be lost, Frank, I assume this is the case. When the system reboots (and it's been >200 days) the kernel forces a filesystem check (it's ext3 on this host). The reason I asked is curiosity what, other than a system crash, could cause inodes to become orphaned. Thanks, Rich ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Orphaned inodes
> On Fri, 28 Jun 2019, Frank Filz wrote: > > > How are you seeing orphaned inodes? > > Frank, > > When the kernel runs fsck on partitions. > > > If the filesystem transactions aren't working right, an orphan inode > > could occur if there was a crash or something during an unlink and the > > directory update was made permanent but the inode cleanup didn't occur. > > Within the past month or so on very infrequent occasions, the desktop reboots > when I turn on the laser printer. The desktop is on a UPS battery backup, the > printer is not. Something new that I'll look into Real Soon Now. Hmm, the crash must be causing open but unlinked inodes to be lost, or some issue during a rename, create, or unlink. Those I would have expected to be handled by the journaling filesystem (are you using one?). I'd actually expect the open unlinked inodes to be caught by the journaling also, but maybe not... Frank ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Orphaned inodes
> What happens to cause inodes to become orphaned? I assume the parents > aren't deported from the system ... or are they? How are you seeing orphaned inodes? An orphan inode should be visible somehow if it represents an open but unlinked file, in that case, that inode will disappear automatically when the file is closed. If the filesystem transactions aren't working right, an orphan inode could occur if there was a crash or something during an unlink and the directory update was made permanent but the inode cleanup didn't occur. Frank ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug