Re: lost+found dir placement
On Tue, Mar 13, 2012 at 2:58 AM, jb jb.1234a...@gmail.com wrote: Hi, Each fs should have its own lost+found directory. It is used by fsck for placing recovered corrupted fs files in there. This implies the dir must have already existed (it may not be mounted ad hoc e.g. at boot time, during fs recovery). In FreeBSD 9, I found lost+found dir under /mnt. This is incorrect - /mnt is defined under all standards (Filesystem Hierarchy Standard, Unix directory structure) as contains filesystem mount points. So, lost+found dir should exist under root dir as /lost+found. Any comments before I file a PR request ? jb The directory is created in the top of the filesystem, so you should check what is mounted on /mnt. Filesystem Hierarchy Standard -- This is a Linux standard. For info on FreeBSD hierarchy see man hier(7) -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: lost+found dir placement
On Tue, 13 Mar 2012 07:58:09 + (UTC), jb wrote: Hi, Each fs should have its own lost+found directory. It is used by fsck for placing recovered corrupted fs files in there. Correct. This implies the dir must have already existed (it may not be mounted ad hoc e.g. at boot time, during fs recovery). No. This implication does not exist. If I read /usr/src/sbin/fsck_ffs/dir.c correctly, the lost+found/ directory will be created by fsck if it is required and _not_ present. It will do so on a inode based method (instead of utilizing a file system oriented call to make a directory). This is a requirement because (as you correctly mentioned) the partition checked will not be writable (or even be mounted), so mkdir() and related fs functions cannot be used. Also see an evidence for that idea in man fsck_ffs. In FreeBSD 9, I found lost+found dir under /mnt. This is incorrect - /mnt is defined under all standards (Filesystem Hierarchy Standard, Unix directory structure) as contains filesystem mount points. According to man hier (mandatory for interpreting the file system hierarchy on FreeBSD) this your assumption sounds correct: /mnt is explained to be an empty directory commonly used by system administrators as a temporary mount point, so having a lost+found/ directory in there doesn't seem to have any purpose and looks wrong. So, lost+found dir should exist under root dir as /lost+found. Correct. It will be assigned to the results of possible recoveries of lost data of the / partition correctly. Any comments before I file a PR request ? If this directory has been created by the installation process, I think you should. Maybe you verify the issue on the freebsd-fs@ list? -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: lost+found dir placement
jb jb.1234a...@gmail.com wrote: Hi, Each fs should have its own lost+found directory. It is used by fsck for placing recovered corrupted fs files in there. This implies the dir must have already existed (it may not be mounted ad hoc e.g. at boot time, during fs recovery). In FreeBSD 9, I found lost+found dir under /mnt. This is incorrect - /mnt is defined under all standards (Filesystem Hierarchy Standard, Unix directory structure) as contains filesystem mount points. So, lost+found dir should exist under root dir as /lost+found. Do you have a filesystem mounted on /mnt? Any comments before I file a PR request ? The fsck_ffs manpage says that 'lost+found' is _created_ *when*needed*, in the root of a filesystem, if not already present. The presense of /mnt/lost+found is _not_ an error. just a surperfluous file that ended up there 'somehow'. *IF* you're going to file a PR, it should be for the filesystem initialization process -- which should (a) create the lost+found directory, (b) create some 'reasonable' number of files in that directory, and (c) then delete all those files. This ensures that the directory exists and has disk-space allocated for a 'reasonable' number of 'recovered' file entries. The existing fsck_ffs has a catastrophic failure mode if there is no space on the disk for the lost+found directory to grow to acomodate the recovered file entries. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: lost+found
# - is a comment.. in bash cd without dirname always return you to a home-directory.. cd - returns you to previous location, for example.. 2009/5/4 Ruben de Groot mai...@bzerk.org On Sat, May 02, 2009 at 11:06:27PM +0200, Polytropon typed: On Sat, 02 May 2009 15:45:13 -0400, PJ af.gour...@videotron.ca wrote: [~]# cd /tmp/lost+found/#123456 [/tmp/lost+found/#123456]# ls Okay, it's empty. [/tmp/lost+found/#123456]# cd .. Strange, why does .. lead you from /tmp/lost+found/#123456 to /tmp/lost+found/#123456, just as if cd wasn't executed? [/tmp/lost+found/#123456]# cd #123456 this returns and empty directory) Does /tmp/lost+found/#123456 contain another #123456? And why does this cd lead you to your (root's) home directory? Probably because the # is interpreted as comment. I can reproduce this in a bourne shell; not in (t)csh. Ruben ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: lost+found
On Sat, May 02, 2009 at 11:06:27PM +0200, Polytropon typed: On Sat, 02 May 2009 15:45:13 -0400, PJ af.gour...@videotron.ca wrote: [~]# cd /tmp/lost+found/#123456 [/tmp/lost+found/#123456]# ls Okay, it's empty. [/tmp/lost+found/#123456]# cd .. Strange, why does .. lead you from /tmp/lost+found/#123456 to /tmp/lost+found/#123456, just as if cd wasn't executed? [/tmp/lost+found/#123456]# cd #123456 this returns and empty directory) Does /tmp/lost+found/#123456 contain another #123456? And why does this cd lead you to your (root's) home directory? Probably because the # is interpreted as comment. I can reproduce this in a bourne shell; not in (t)csh. Ruben ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: lost+found
On Mon, 4 May 2009 11:08:04 +0200, Ruben de Groot mai...@bzerk.org wrote: Probably because the # is interpreted as comment. I can reproduce this in a bourne shell; not in (t)csh. Ah, thank you. According to the prompt, it didn't look like csh in the first place, but not like plain sh, too. Customized bash prompts usually include brackets 'n stuff. Because I'm using csh mostly, I didn't see the problem that cd #something == cd (which of course leads to $HOME). An attempt to rm #12345 in sh / bash should lead to an error message (for incomplete rm command). It's safe to use the Midnight Commander to cd into and rm #something files and directories. :-) -- Polytropon From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: lost+found
On Sat, 02 May 2009 15:45:13 -0400, PJ af.gour...@videotron.ca wrote: [~]# cd /tmp/lost+found/#123456 [/tmp/lost+found/#123456]# ls Okay, it's empty. [/tmp/lost+found/#123456]# cd .. Strange, why does .. lead you from /tmp/lost+found/#123456 to /tmp/lost+found/#123456, just as if cd wasn't executed? [/tmp/lost+found/#123456]# cd #123456 this returns and empty directory) Does /tmp/lost+found/#123456 contain another #123456? And why does this cd lead you to your (root's) home directory? [~]# ls (this returns the listing of the contents of /root Of course, because CWD is ~ now. Whoops! What is going on? I'd like to delete this /tmp/lost+found/ directory but, being very wary, I don't want to take the risk (probably none) to delete it since there is no indication that this is a symbolic link and might delte the actual /root/ directory withoug getting some information about this occurrence. The best idea would be to copy the content of /root into another directory first, then performing the rm operation, and afterwards, if something went wrong, restore /root from this backup copy. Very strange... Just to be sure, are you SURE you reported the paths (in the prompt) and the commands correctly? -- Polytropon From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: lost+found
In response to Dave [EMAIL PROTECTED]: Hello, What is lost+found? I've got one on all my filesystems and over the past few days i've had things being deleted from there. Do i have a problem? When fsck finds problems with the filesystem, it saves any data that otherwise may have been lost to this directory. This is likely to happen if your system is powered off without a proper shutdown. If you use softupdates on your filesystems, this is not done because softupdates has other ways to deal with the problem. Don't shut off your system without properly unmounting the filesystems and you won't have this problem. If you aren't missing any data, you can delete the files in there. -- Bill Moran http://www.potentialtech.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lost+found
Bill Moran writes: What is lost+found? I've got one on all my filesystems and over the past few days i've had things being deleted from there. Do i have a problem? When fsck finds problems with the filesystem, it saves any data that otherwise may have been lost to this directory. To elaborate a little: When fsck finds a file that no directory thinks belongs to it. it stores that file in the lost+found directory of that partition as #inode. Robert huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: lost+found
Hello Chuck, Jerlique Bahn wrote: If I pull the power on my server whilst its doing heavy IO, should I get files in lost+found if my raid card has battery backed cache? Yes, it's still possible. The cache on the RAID card will be flushed OK, but any in-process operations by live processes will be interrupted in the middle if the OS goes away. While some operations are atomic (things like unlink or move), simply writing pieces out is not... Ok, this is contrary to what was my belief, but I guess it really does makes sense. Eg Suppose we are talking about writing a 1gb file. This obviously needs to be written to the disk, and not stored in cache. So can you explain the process of ufs writing the file, and what ends up in lost+found if the server is rebooted part way through eg say we are 3/4 of the way through writing the file before reboot. Or better still are there any semi-technical white papers/web-pages which could explain this, and under what circumstances lost+found is used. I would like to also know how to turn off (or check) caching on the physical disk itself. smartmontools port? sysctl hw.ata.wc...? Sorry I should have mentioned I'm using SCSI disks behind a raid card ;) Thanks for your comments! JB ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lost+found
Jerlique Bahn wrote: If I pull the power on my server whilst its doing heavy IO, should I get files in lost+found if my raid card has battery backed cache? Yes, it's still possible. I was under the understanding that the file operations were atomic, and hence freebsd's file system should have no corrupted files on the reboot. The raid card says that it is flushing the cache of the card, yet freebsd still experiences the corrupt files. The cache on the RAID card will be flushed OK, but any in-process operations by live processes will be interrupted in the middle if the OS goes away. While some operations are atomic (things like unlink or move), simply writing pieces out is not... What should I be looking for? I would like to also know how to turn off (or check) caching on the physical disk itself. smartmontools port? sysctl hw.ata.wc...? -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lost+found
On Sat, May 13, 2006 at 11:42:54PM +0200, Jose Luis Alarcon Sanchez wrote: Hi. Why the structure of directories in FreeBSD don't have a lost+found directory?. (Talking about 6.x Releases) Some Unix manuals tell that this directory is very important for the work of the fsck program... Indeed. And if ever fsck needs one, it creates it. I know from bitter personal experience! Dan -- Daniel Bye PGP Key: http://www.slightlystrange.org/pgpkey-dan.asc PGP Key fingerprint: D349 B109 0EB8 2554 4D75 B79A 8B17 F97C 1622 166A _ ASCII ribbon campaign ( ) - against HTML, vCards and X - proprietary attachments in e-mail / \ pgpLxykq10U0R.pgp Description: PGP signature
Re: Lost + Found
On Tue, Nov 19, 2002 at 12:10:33PM +0200, Doron Shmaryahu wrote: I had a server which due to power problems rebooted a couple of times. I did a fsck, because it kept complaining about inconsistencies. Now some directories seem to have moved. I located them in lost + found. Is there any way to recover these files from there ?? lost+found is where fsck(8) puts files or directories it finds on the disk but that it can't place correctly into the filesystem because of damage to directories further up the tree. Just mv(1) the data back to where it came from. Unfortunately, there's no record kept on the system of where that was, so you'll just have to remember for yourself as well as you can. Note that if you're seeing stuff in lost and found, then it's quite possible that there were other files that have disappeared completely. You may have to recover the partition from backup to ensure that everything is consistent. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
