tag:blogger.com,1999:blog-11788780.post9471158093475831..comments2023-12-29T13:22:33.104-08:00Comments on JJinuxLand: Linux: Fun with Big Filesjjinuxhttp://www.blogger.com/profile/03270879497119114175noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-11788780.post-2451204638294657122009-01-20T00:14:00.000-08:002009-01-20T00:14:00.000-08:00Haha, nice! ;)Haha, nice! ;)jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-33270531305377696882009-01-20T00:12:00.000-08:002009-01-20T00:12:00.000-08:00Hahaha, sorry JJ, I'd love to help you but FreeBSD...Hahaha, sorry JJ, I'd love to help you but FreeBSD is lacking Linux's freeze-while-it-performs-IO feature.<BR/><BR/>But, as you say, a file remains open so long as any process retains a handle to it (even if there is no name associated with the file in the filesystem). This is a common problem with naive log-rotation scripts: they rename the log file without signaling to the logging process that it needs to reopen the log file. As such, the process continues to write to the "old" file and the "new" file remains 0 bytes in size. This is because the mv operation (and rm/unlink operation) only modify directory entries, they do not touch the inode. Incidentally, that is also why stat(2)'s mtime and atime fields don't reflect name changes to files...stat only returns information about the inode, not anything about the (possibly multiple) names referring to the file.<BR/><BR/>Since you asked, the relevant logic in the FreeBSD kernel starts with the vput() and vrele() routines in src/sys/kern/vfs_subr.c. These are two variants of the drop reference part of the kernel's file handle reference counting code. When the reference count drops to zero, these routines call vinactive() which, in turn, calls the filesystem-specific implementation of the vfs_inactive callback. For the default UFS filesystem, that callback is ufs_inactive() in src/sys/ufs/ffs/ufs_inode.c.<BR/><BR/>Anyway, I don't recall FreeBSD ever having long stalls while deleting files, but that really depends on the I/O scheduler. I'm not a Linux expert by any means, but perhaps you're experiencing this bug:<BR/>http://it.slashdot.org/article.pl?sid=09/01/15/049201<BR/><BR/>Enjoying the blog as always, JJ. Even if you do put me on the spot. :)<BR/><BR/>KellyKelly Yanceyhttps://www.blogger.com/profile/08648597728708472240noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-66841886239096350212009-01-19T22:51:00.000-08:002009-01-19T22:51:00.000-08:00Hahaha. Nah, I'll just wait for Kelly Yancey to t...Hahaha. Nah, I'll just wait for Kelly Yancey to tell me. He'll reply with the actual code from FreeBSD's kernel that would explain the situation ;)jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-64554559586744436492009-01-19T16:17:00.000-08:002009-01-19T16:17:00.000-08:00and then jj had to get all smart and suggest the s...and then jj had to get all smart and suggest the shell is waiting on waitpid(). Only he can tell us. :-)Brandon L. Golmhttps://www.blogger.com/profile/12579635831136709134noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-70786943772753631622009-01-19T09:03:00.000-08:002009-01-19T09:03:00.000-08:00just making this up here, but the shell was probab...just making this up here, but the shell was probably blocked on IO. Remember that the shell creates three pipes, forks, and dups those pipes over to 0,1,2, does a setgrp, then execs whatever process (order, completeness, and accuracy are approximate). But the whole time, the shell is reading from those pipes (and spewing it back at you).<BR/><BR/>So when the process is completely stuck in some kernel place that isn't supposed to take long, there's probably something funny that happens with select or whatever, so the shell's routines that normally don't block ... are blocked.<BR/><BR/>That's *my* guess.Brandon L. Golmhttps://www.blogger.com/profile/12579635831136709134noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-88713458850800378592009-01-18T23:06:00.000-08:002009-01-18T23:06:00.000-08:00> Given that this is reproducible, it might be ...> Given that this is reproducible, it might be fun to test your hypothesis with lsof.<BR/><BR/>Interesting idea. I'm almost 100% certain that the program still had the file open even though you couldn't reference it via the filesystem. That just makes sense.<BR/><BR/>The one thing I'm not 100% certain of is whether the shell was frozen because the kernel was releasing inodes. My guess is that the file was deleted, and then the kernel started deleting files. Since the program was no longer visible via "ps aux", I'm guessing "lsof" would also not see the file.jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-65888251606418523322009-01-18T23:03:00.000-08:002009-01-18T23:03:00.000-08:00Given that this is reproducible, it might be fun t...Given that this is reproducible, it might be fun to test your hypothesis with lsof.Anonymousnoreply@blogger.com