11-04-2013 01:36 PM - edited 03-07-2019 04:25 PM
Does anyone know what feature is causing this? My customer is extremely detail oriented and I'm trying to find an answer.
Directory of disk0:/
4 drw- 0 Oct 25 2013 15:29:44 -05:00 ORPHAN1
9 -rw- 55143 Jul 29 2013 15:03:22 -05:00 logfile.txt
13 -rw- 85814640 Dec 6 2012 13:49:38 -06:00 s2t54-ipservicesk9-mz.SPA.150-1.SY1.bin
14 drw- 0 Apr 9 2013 13:45:38 -05:00 archive
91 -rw- 93441464 May 7 2013 09:51:24 -05:00 s2t54-ipservicesk9-mz.SPA.151-1.SY1.bin
Directory of disk0:/ORPHAN1/
5 -rw- 98304 Oct 25 2013 15:29:44 -05:00 orphan_1
6 -rw- 131072 Oct 25 2013 15:29:46 -05:00 orphan_2
7 -rw- 131072 Oct 25 2013 15:29:46 -05:00 orphan_3
1024557056 bytes total (836124672 bytes free)
Cisco IOS Software, s2t54 Software (s2t54-IPSERVICESK9-M), Version 15.1(1)SY1, RELEASE SOFTWARE (fc5)
.
.
.
ROM: System Bootstrap, Version 12.2(50r)SYS2, RELEASE SOFTWARE (fc1)
xxxxxxxxxx uptime is 7 weeks, 4 days, 1 hour, 15 minutes
Uptime for this control processor is 7 weeks, 4 days, 22 minutes
System returned to ROM by Stateful Switchover at 16:10:46 cdt Thu Sep 12 2013
System restarted at 16:11:41 cdt Thu Sep 12 2013
System image file is "bootdisk:s2t54-ipservicesk9-mz.SPA.151-1.SY1.bin"
Last reload reason: Admin CLI
.
.
.
cisco WS-C6509-E (M8572) processor (revision ) with 1785856K/262144K bytes of memory.
Processor board ID SMG1626N07A
CPU: MPC8572_E, Version: 2.2, (0x80E80022)
CORE: E500, Version: 3.0, (0x80210030)
CPU:1500MHz, CCB:600MHz, DDR:600MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Last reset from s/w reset
20 Virtual Ethernet interfaces
204 Gigabit Ethernet interfaces
8 Ten Gigabit Ethernet interfaces
2543K bytes of non-volatile configuration memory.
Configuration register is 0x2102
11-04-2013 02:49 PM
Derek,
I believe that these orphan files are the result of the filesystem check run either during boot or invoked using the fsck privileged EXEC command. Orphan files are files that have been deleted while being opened by a process, so they remained in existence but they lost any reference to a directory where they were formerly placed. The operating system should have pruned them from the filesystem once they have been closed but because of whatever reason (sudden restart, bug, etc.), it did not do so.
On Linux filesystems, these orphaned files are placed upon filesystem check into a so-called lost+found directory. Here, it would appear that the filesystem check created a separate directory and put the files there.
I can not support this claim with any documentation but this would be my understanding of the entire issue. In any case, these orphan files should not multiply - and if they do, this would be a case for a TAC.
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide