From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: unlinked orphans.
Date: Mon, 23 Dec 2013 10:10:25 +0000 (UTC) [thread overview]
Message-ID: <pan$484a5$e3c30cf5$18e2aa4e$b79770e@cox.net> (raw)
In-Reply-To: 20131223093953.GH17179@carfax.org.uk
Hugo Mills posted on Mon, 23 Dec 2013 09:39:53 +0000 as excerpted:
> On Sun, Dec 22, 2013 at 10:27:17PM -0800, Nacho Man wrote:
>> I ran dmesg and saw a bunch of these:
>> [564421.874063] BTRFS debug (device sda2): unlinked 32 orphans
>>
>> Do I have to worry?
> No, this is harmless. Orphans are files that were deleted while
> they were still held open by a process. POSIX semantics requires that
> the file data is still readable by the process, but that the file's
> hardlink(s) are no longer visible -- so there's no way of finding the
> file again by "normal" methods. Once the process closes the file, it is
> unlinked.
Cool. I knew delete worked that way on POSIX filesystems[1], and I'd
seen various posts on this list with unlinking X orphans logs, but I had
no idea /that/ was what orphans referred too!
New logical connection made. Thanks. =:^)
> With btrfs, making a snapshot of a subvolume with (still open)
> orphan files in it will close the orphans on the new copy, because
> they're new files. This leads to the messages above.
... And that's entirely logical, once one actually knows what "orphans"
are! =:^)
---
[1] Someone posted a script to the gentoo-dev list at one point, that can
be run after an update to go thru /proc and list the processes that have
open but deleted files... because they've been replaced in the update.
That way, an admin can see what still-running apps still have outdated
and possibly vulnerable libraries loaded, and can choose to restart those
apps, or leave them running, or look a bit closer at what libs that
process depends on that were updated and why, before choosing to restart
that process, as appropriate based on the risk factor for that process vs
whether it's doing something important that can't be interrupted without
losing data. Using that tool and seeing just what tends to need
restarted after an update as well as how frequently, is what really drove
home the principle here, but I didn't know what those deleted-but-still-
open files were called, until your explanation just now. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2013-12-23 10:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-23 6:27 unlinked orphans Nacho Man
2013-12-23 9:39 ` Hugo Mills
2013-12-23 10:10 ` Duncan [this message]
2013-12-24 6:16 ` Nacho Man
2014-01-02 16:04 ` David Sterba
2013-12-23 17:16 ` Chris Murphy
2014-01-02 16:21 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$484a5$e3c30cf5$18e2aa4e$b79770e@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.