Re: lost+found dir placement
On Tue, 13 Mar 2012 10:02:16 + (UTC), jb wrote: > Robert Bonomi mail.r-bonomi.com> writes: > > > ... > > 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'. > > ... > > This worried me. And still does ... How "clean" is your installation? If you have had mounted some UFS file system in /mnt that has undergone a fsck check where the creation of lost+found had been neccessary... no wait, it would be on that partition then. If this directory entry is present in /mnt which is supposed to be empty by default, e. g. if "mount" doesn't show something actually mounted on /mnt, then I think you should delete the directory entry. Just imagine the "fun" that could happen if you mount something to /mnt... However, do you remember _what_ created lost+found in /mnt? > > *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. > > > > That's perhaps why under Linux they have special mklost+found entry ? Nothing new. In fact, I remember that my WEGA (UNIX system III derivate) mentiones a command that would create the lost+found directory, mklf or createlf... as a binary. > > 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. > > > > I was surprised to find empty lost+found dir in /mnt. > drwx-- 2 root wheel 512 May 5 2011 lost+found > That's why I jumped a bit. It's fully unsurprising to be surprised here. :-) > Few days ago, after clean reboot to single user mode, I tested fsck manually > on SUJ fs and found things that seemed to be questionable (I posted it on > current@ list, if you want to take a look). > > So, it must have happened during that time, because as I said I did not have > any forced fsck run at boot times, and I almost swear I did not have this > lost+found dir in /mnt before. Possible, but in a normal case, lost+found is tied to a partition (and per implication to a mountpoint). The mountpoint, if _not_ in use, should be empty. > I will take a look at source code of fsck* entries and perhaps find a clue. I posted the file name where you can find the handling of the creation of lost+found. Just search for this string and you'll find the corresponding section easily. -- 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
Robert Bonomi mail.r-bonomi.com> writes: > ... > 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'. > ... This worried me. And still does ... > *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. > That's perhaps why under Linux they have special mklost+found entry ? > 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. > I was surprised to find empty lost+found dir in /mnt. drwx-- 2 root wheel 512 May 5 2011 lost+found That's why I jumped a bit. Few days ago, after clean reboot to single user mode, I tested fsck manually on SUJ fs and found things that seemed to be questionable (I posted it on current@ list, if you want to take a look). So, it must have happened during that time, because as I said I did not have any forced fsck run at boot times, and I almost swear I did not have this lost+found dir in /mnt before. I will take a look at source code of fsck* entries and perhaps find a clue. jb ___ 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 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 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
On Tue, Mar 13, 2012 at 2:58 AM, 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. > 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"
lost+found dir placement
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 ___ 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 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
"#" - 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 > On Sat, May 02, 2009 at 11:06:27PM +0200, Polytropon typed: > > On Sat, 02 May 2009 15:45:13 -0400, PJ 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 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 Sat, 02 May 2009 15:45:13 -0400, PJ 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"
lost+found
A couple of days ago I had minor glitch as my FreeBSD box on my local intranet had an unexpected shutdown. When I fsck'd on reboot I was left with a few lost+found directories with #99 files. Most appeared inconsequential and could be deleted. But there is one /tmp/lost+found that puzzles me. There are 3 subdirectories that act a little strangely. [~]# cd /tmp/lost+found/#123456 [/tmp/lost+found/#123456]# ls [/tmp/lost+found/#123456]# cd .. [/tmp/lost+found/#123456]# cd #123456 this returns and empty directory) [~]# ls (this returns the listing of the contents of /root 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. TIA. -- Hervé Kempf: "Pour sauver la planète, sortez du capitalisme." - Phil Jourdan --- p...@ptahhotep.com http://www.ptahhotep.com http://www.chiccantine.com/andypantry.php ___ 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: No space in lost+found directory (formerly: SORRY. NO SPACE IN lost+found DIRECTORY)
On Thu, Apr 16, 2009 at 08:30:40PM +0200, Polytropon wrote: > On Thu, 16 Apr 2009 15:21:28 +0100, Chris Rees wrote: > > 2009/4/16 Bruce Cran : > > > Maybe we should tell FreeBSD to stop shouting too? :) > > > > Actually, we really should! Come on, we're not on teletypes any more. > > Did UPPERCASE LETTERS make the teletype print louder? > I always assumed they would just consume more disk space... > RYRYRYRYRYRYRY!!! :-) Nah, the earliest ones only had upper case. When they made upper/lower models, for some reason people just left on shift-lock - maybe to make it look the same. jerry > > > -- > 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" ___ 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: No space in lost+found directory (formerly: SORRY. NO SPACE IN lost+found DIRECTORY)
On Thu, 16 Apr 2009 15:21:28 +0100, Chris Rees wrote: > 2009/4/16 Bruce Cran : > > Maybe we should tell FreeBSD to stop shouting too? :) > > Actually, we really should! Come on, we're not on teletypes any more. Did UPPERCASE LETTERS make the teletype print louder? I always assumed they would just consume more disk space... RYRYRYRYRYRYRY!!! :-) -- 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: No space in lost+found directory (formerly: SORRY. NO SPACE IN lost+found DIRECTORY)
2009/4/16 Bruce Cran :
> On Thu, 16 Apr 2009 14:03:58 +0100
> Chris Rees wrote:
>
> 2009/4/16 vijay kumar :
>>>
>>> SORRY. NO SPACE IN lost+found DIRECTORY
>
>> Please don't shout.
>
> fsfsck_ffs/dir.c:467: pfatal("SORRY. NO SPACE IN
> lost+found DIRECTORY"
>
> Maybe we should tell FreeBSD to stop shouting too? :)
>
> --
> Bruce Cran
>
Actually, we really should! Come on, we're not on teletypes any more.
Chris
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
___
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: No space in lost+found directory (formerly: SORRY. NO SPACE IN lost+found DIRECTORY)
On Thu, 16 Apr 2009 14:03:58 +0100
Chris Rees wrote:
2009/4/16 vijay kumar :
>>
>> SORRY. NO SPACE IN lost+found DIRECTORY
> Please don't shout.
fsfsck_ffs/dir.c:467: pfatal("SORRY. NO SPACE IN
lost+found DIRECTORY"
Maybe we should tell FreeBSD to stop shouting too? :)
--
Bruce Cran
___
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"
No space in lost+found directory (formerly: SORRY. NO SPACE IN lost+found DIRECTORY)
Pasted from subject: 2009/4/16 vijay kumar : > > SORRY. NO SPACE IN lost+found DIRECTORY Please don't shout. Have you checked that / has sufficient space? Try root # fsck / --- root # df -h and post the result. Regards, Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ 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: SORRY. NO SPACE IN lost+found DIRECTORY
Sorry, no contents in email. ___ 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"
SORRY. NO SPACE IN lost+found DIRECTORY
___ 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"
Ran fsck, now all files are in lost+found
So, I moved a RAID5 device between a FreeBSD 6.0 machine to fresh FreeBSD 7.0 machine. When I attempted to mount the device the OS complained that the disk had not bee unmounted properly -- figuring it was probably correct, I diligently dropped to single user mode and ran fsck on the disk. I ran 'fsck -t ufs -y'. all seemed fine and dandy until I tried to remount the volume after bringing it back to multi-user mode. The disk space was occupied, but it all resided in lost+found with names like : #001 , #002 etc... !! Each file was multiple gigabytes worth of data without file structures (as far as I could tell) Is there an way to recover from this problem ? I would be losing quite a lot of data, any help you could give would be appreciated. Help, B ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
lost+found help please
Yesterday my server rebooted for some unknown reason and after fsck- ing 4 times I had ALOT of stuff in lost+found. I really need to try and review/recover these files. Only docs I've found were linux centric, and focused on directories and dates. I can't make out either here. Please take a look at this "http://www.mtadistributors.com/listing.txt"; I'd appreciate any advise you may have to offer. Thanks Troy Kocher _ Scanned by IBM Email Security Management Services powered by MessageLabs. _ ___ 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 "#". 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
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]"
lost+found
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? Thanks. Dave. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: removing large files (lost+found)
Dan Nelson wrote: In the last episode (Aug 02), Scott Oertel said: Dan Nelson wrote: In the last episode (Aug 02), Scott Oertel said: Yesterday after an fsck a file was placed in the lost+found folder which size was exactly the size of the drive (450gb). What is the safest way to remove this file? If its timestamp updates when you touch a file on the main filesystem, it's most likely a snapshot file, either leftover from a failed background fsck, or manually created by you with mksnap_ffs. You can just delete it. The time stamp doesn't update, it gives an error: touch: #0005: Operation not permitted I mean touch some other file :) But I just remembered the correct way to determine if a file is a snapshot: "ls -lo". If the flags field contains the word "snapshot" for that file, it's a snapshot. Good call, yeah.. it is a snap shot file, I suppose I'll try and remove it, hopefully removing a 450GB file doesn't lock up the system.. # ls -lo -r 1 root operator snapshot 482801995408 Jul 31 05:52 #0005 Thanks, Scott Oertel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: removing large files (lost+found)
In the last episode (Aug 02), Scott Oertel said: > Dan Nelson wrote: > >In the last episode (Aug 02), Scott Oertel said: > >>Yesterday after an fsck a file was placed in the lost+found folder > >>which size was exactly the size of the drive (450gb). What is the > >>safest way to remove this file? > > > >If its timestamp updates when you touch a file on the main > >filesystem, it's most likely a snapshot file, either leftover from a > >failed background fsck, or manually created by you with mksnap_ffs. > >You can just delete it. > > The time stamp doesn't update, it gives an error: touch: #0005: > Operation not permitted I mean touch some other file :) But I just remembered the correct way to determine if a file is a snapshot: "ls -lo". If the flags field contains the word "snapshot" for that file, it's a snapshot. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: removing large files (lost+found)
Dan Nelson wrote: In the last episode (Aug 02), Scott Oertel said: Yesterday after an fsck a file was placed in the lost+found folder which size was exactly the size of the drive (450gb). What is the safest way to remove this file? If its timestamp updates when you touch a file on the main filesystem, it's most likely a snapshot file, either leftover from a failed background fsck, or manually created by you with mksnap_ffs. You can just delete it. The time stamp doesn't update, it gives an error: touch: #0005: Operation not permitted -Scott Oertel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: removing large files (lost+found)
In the last episode (Aug 02), Scott Oertel said: > Yesterday after an fsck a file was placed in the lost+found folder which > size was exactly the size of the drive (450gb). What is the safest way > to remove this file? If its timestamp updates when you touch a file on the main filesystem, it's most likely a snapshot file, either leftover from a failed background fsck, or manually created by you with mksnap_ffs. You can just delete it. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
removing large files (lost+found)
Yesterday after an fsck a file was placed in the lost+found folder which size was exactly the size of the drive (450gb). What is the safest way to remove this file? Thanks, Scott Oertel ___ 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]"
lost+found
Hello, 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? 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. What should I be looking for? I would like to also know how to turn off (or check) caching on the physical disk itself. 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
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
lost+found
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... Thanks very much, in advance. Regards. Jose. -- http://www.lordofunix.org/ Not Registered GNU/Hurd User. Registered BSD User 51101. Registered Linux User #213309. Memories. You are talking about memories. Rick Deckard. Blade Runner. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
How do you increase the size of lost+found?
While trying to recover from a HD crash, 'fsck -y /dev/rad1s1a' reports the following error a number of times at the end of it's run: UNREF FILE I=3537799 OWNER=500 MODE=100644 SIZE=6611 MTIME=Oct 25 21:12 2003 RECONNECT? yes SORRY. NO SPACE IN lost+found DIRECTORY This tells me that it's not saving some of the files on the drive. Is that correct? Is there anything I can do to make more space in lost+found, either system-wide or while the fsck is running? Some possibly pertinent info: # ls -lad lost+found drwxrwxrwt 1379 root wheel 182272 Apr 12 16:55 lost+found # ls lost+found | wc -l 8899 This fs was copied from a drive reporting "hard errors reading fsbn..." using dd. Thanks, Brad Waite ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SORRY. NO SPACE IN lost+found DIRECTORY
While trying to recover from a HD crash, 'fsck -y /dev/rad1s1a' reports the following error a number of times at the end of it's run. UNREF FILE I=3537799 OWNER=500 MODE=100644 SIZE=6611 MTIME=Oct 25 21:12 2003 RECONNECT? yes SORRY. NO SPACE IN lost+found DIRECTORY This tells me that it's not saving some of the files on the drive. Is that correct? Is there anything I can do to make more space in lost+found, either system-wide or while the fsck is running? Some possibly pertinent info: # ls -lad lost+found drwxrwxrwt 1379 root wheel 182272 Apr 12 16:55 lost+found # ls lost+found | wc -l 8899 This fs was copied from a drive reporting "hard errors reading fsbn..." using dd. Thanks, Brad Waite ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: deleting lost+found directory
On Sat, 6 Mar 2004, Vincent Poy wrote:
> On Sat, 6 Mar 2004, Kris Kennaway wrote:
>
> > On Sat, Mar 06, 2004 at 04:03:35PM -1000, Vincent Poy wrote:
> >
> > > > > > > > They're just directories, remove them in the usual way.
> > > > > > >
> > > > > > > Tried that, didn't work...
> > > > > >
> > > > > > > [EMAIL PROTECTED] [4:00pm][/mnt/usr/lost+found] >> rm -rf *
> > > > > > > rm: #5558272: Directory not empty
> > > > > > > rm: #7018496: Directory not empty
> > > > > > > rm: #7206914: Directory not empty
> > > > > > > rm: #7254025: Directory not empty
> > > > > > > rm: #7254167: Directory not empty
> > > > > >
> > > > > > Unmount the filesystem and run fsck again (e.g. with the -f flag).
> > > > > > You seem to have additional filesystem corruption here.
> > > > >
> > > > > I did fsck with the -fy flag just now and this is what it says:
> > > > >
> > > > > UNREF DIR I=471104 OWNER=root MODE=40755
> > > > > SIZE=512 MTIME=Mar 1 04:00 2004
> > > > > RECONNECT? yes
> > > > >
> > > > > SORRY. NO SPACE IN lost+found DIRECTORY
> > > > > UNEXPECTED SOFT UPDATE INCONSISTENCY
> > > >
> > > > Is the disk full or out of inodes?
> > >
> > > Not sure about the inodes but the disk is at 0% capacity as ad2s1a
> > > doesn't have any problems. ad2s1d is the one where I rm -rf . since that
> > > is used to do a dump,restore of /usr.
> >
> > I don't understand which disk is which..can you please describe your
> > configuration in more detail?
>
> Okay, let's see...
>
> /dev/ad0 and /dev/ad2 are identical drives (Hitachi TravelStar 2.5"
> 7200RPM 60GB)
>
> /dev/ad0s1a is 128MB for / - 54% capacity
> /dev/ad0s1b is 256MB for swap
> /dev/ad0s1d is 56.3GB for /usr - 11% capacity
>
> /dev/ad2s1a is 128MB for /mnt/root - 54% capacity
> /dev/ad0s1b is 256MB for swap
> /dev/ad0s1d is 56.3GB for /mnt/usr - 11% capacity max
>
> Basically, /mnt/root is a clone of / and /mnt/usr is a clone of
> /usr which is done as follows:
>
> cd /mnt/root
> /bin/chflags -R noschg .
> /bin/rm -rf .*
> /bin/rm -rf *
> /sbin/dump -L -f- /|restore -rf-
> cd /mnt/usr
> /bin/chflags -R noschg .
> /bin/rm -rf .*
> /bin/rm -rf *
> /sbin/dump -L -f- /usr|restore -rf-
>
> /mnt/usr is the one with the problem I mentioned which is due to
> an upgrade of -CURRENT to February 28, 2003 and even March 5, 2003 from
> the September 26, 2003 which was working fine but now whenever this script
> executes at 4AM, it causes a kernel panic with the following:
>
> panic: kmem_malloc (4096): kmem_map too small: 377487360 total allocated
>at line 341 in file /usr/src/sys/vm/vm_kern.c
> cpuid=0;
> Debugger("panic")
> Stopped at Debugger+0x46: xchgl %ebx, in_Debugger.0
> db>
>
> The script runs fine if I do it manually after a few minutes after
> a reboot.
>
> I've tried adding the following to the kernel config, building and
> installing the kernel
>
> options VM_KMEM_SIZE_MAX=(768*1048576)
> options VM_KMEM_SIZE_SCALE=2
>
> as well as adding vm.kmem_size=429391872 to /boot/loader.conf to the
> without the above options and they both panic right after this part:
>
> CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.60GHz (2592.36-MHz 686-class
> CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9
>
> Features=0xbfebf9ff AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> real memory = 2147360768 (2047 MB)
> avail memory = 2095669248 (1998 MB)
>
> with something having to do with vm_kern.c.
Just an update, fixed the problem. Seems like I had to do
fsck -fyp /dev/ad2s1d followed by fsck -fy /dev/ad2s1d and then repeat the
same process again until neither one of them complains which took 5-6
passes. Thanks Kris!
Cheers,
Vince - [EMAIL PROTECTED] - Vice President __
Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ]
WurldLink Corporation / / / / | / | __] ]
San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ]
HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[]
[EMAIL PROTECTED] - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: deleting lost+found directory
On Sat, 6 Mar 2004, Kris Kennaway wrote:
> On Sat, Mar 06, 2004 at 04:03:35PM -1000, Vincent Poy wrote:
>
> > > > > > > They're just directories, remove them in the usual way.
> > > > > >
> > > > > > Tried that, didn't work...
> > > > >
> > > > > > [EMAIL PROTECTED] [4:00pm][/mnt/usr/lost+found] >> rm -rf *
> > > > > > rm: #5558272: Directory not empty
> > > > > > rm: #7018496: Directory not empty
> > > > > > rm: #7206914: Directory not empty
> > > > > > rm: #7254025: Directory not empty
> > > > > > rm: #7254167: Directory not empty
> > > > >
> > > > > Unmount the filesystem and run fsck again (e.g. with the -f flag).
> > > > > You seem to have additional filesystem corruption here.
> > > >
> > > > I did fsck with the -fy flag just now and this is what it says:
> > > >
> > > > UNREF DIR I=471104 OWNER=root MODE=40755
> > > > SIZE=512 MTIME=Mar 1 04:00 2004
> > > > RECONNECT? yes
> > > >
> > > > SORRY. NO SPACE IN lost+found DIRECTORY
> > > > UNEXPECTED SOFT UPDATE INCONSISTENCY
> > >
> > > Is the disk full or out of inodes?
> >
> > Not sure about the inodes but the disk is at 0% capacity as ad2s1a
> > doesn't have any problems. ad2s1d is the one where I rm -rf . since that
> > is used to do a dump,restore of /usr.
>
> I don't understand which disk is which..can you please describe your
> configuration in more detail?
Okay, let's see...
/dev/ad0 and /dev/ad2 are identical drives (Hitachi TravelStar 2.5"
7200RPM 60GB)
/dev/ad0s1a is 128MB for / - 54% capacity
/dev/ad0s1b is 256MB for swap
/dev/ad0s1d is 56.3GB for /usr - 11% capacity
/dev/ad2s1a is 128MB for /mnt/root - 54% capacity
/dev/ad0s1b is 256MB for swap
/dev/ad0s1d is 56.3GB for /mnt/usr - 11% capacity max
Basically, /mnt/root is a clone of / and /mnt/usr is a clone of
/usr which is done as follows:
cd /mnt/root
/bin/chflags -R noschg .
/bin/rm -rf .*
/bin/rm -rf *
/sbin/dump -L -f- /|restore -rf-
cd /mnt/usr
/bin/chflags -R noschg .
/bin/rm -rf .*
/bin/rm -rf *
/sbin/dump -L -f- /usr|restore -rf-
/mnt/usr is the one with the problem I mentioned which is due to
an upgrade of -CURRENT to February 28, 2003 and even March 5, 2003 from
the September 26, 2003 which was working fine but now whenever this script
executes at 4AM, it causes a kernel panic with the following:
panic: kmem_malloc (4096): kmem_map too small: 377487360 total allocated
at line 341 in file /usr/src/sys/vm/vm_kern.c
cpuid=0;
Debugger("panic")
Stopped at Debugger+0x46: xchgl %ebx, in_Debugger.0
db>
The script runs fine if I do it manually after a few minutes after
a reboot.
I've tried adding the following to the kernel config, building and
installing the kernel
options VM_KMEM_SIZE_MAX=(768*1048576)
options VM_KMEM_SIZE_SCALE=2
as well as adding vm.kmem_size=429391872 to /boot/loader.conf to the
without the above options and they both panic right after this part:
CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.60GHz (2592.36-MHz 686-class
CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9
Features=0xbfebf9ff
real memory = 2147360768 (2047 MB)
avail memory = 2095669248 (1998 MB)
with something having to do with vm_kern.c.
Cheers,
Vince - [EMAIL PROTECTED] - Vice President __
Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ]
WurldLink Corporation / / / / | / | __] ]
San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ]
HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[]
[EMAIL PROTECTED] - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: deleting lost+found directory
On Sat, Mar 06, 2004 at 04:03:35PM -1000, Vincent Poy wrote: > > > > > > They're just directories, remove them in the usual way. > > > > > > > > > > Tried that, didn't work... > > > > > > > > > [EMAIL PROTECTED] [4:00pm][/mnt/usr/lost+found] >> rm -rf * > > > > > rm: #5558272: Directory not empty > > > > > rm: #7018496: Directory not empty > > > > > rm: #7206914: Directory not empty > > > > > rm: #7254025: Directory not empty > > > > > rm: #7254167: Directory not empty > > > > > > > > Unmount the filesystem and run fsck again (e.g. with the -f flag). > > > > You seem to have additional filesystem corruption here. > > > > > > I did fsck with the -fy flag just now and this is what it says: > > > > > > UNREF DIR I=471104 OWNER=root MODE=40755 > > > SIZE=512 MTIME=Mar 1 04:00 2004 > > > RECONNECT? yes > > > > > > SORRY. NO SPACE IN lost+found DIRECTORY > > > UNEXPECTED SOFT UPDATE INCONSISTENCY > > > > Is the disk full or out of inodes? > > Not sure about the inodes but the disk is at 0% capacity as ad2s1a > doesn't have any problems. ad2s1d is the one where I rm -rf . since that > is used to do a dump,restore of /usr. I don't understand which disk is which..can you please describe your configuration in more detail? Kris pgp0.pgp Description: PGP signature
Re: deleting lost+found directory
On Sat, 6 Mar 2004, Kris Kennaway wrote: > On Sat, Mar 06, 2004 at 03:53:13PM -1000, Vincent Poy wrote: > > On Sat, 6 Mar 2004, Kris Kennaway wrote: > > > > > On Sat, Mar 06, 2004 at 02:00:12PM -1000, Vincent Poy wrote: > > > > > > > > They're just directories, remove them in the usual way. > > > > > > > > Tried that, didn't work... > > > > > > > [EMAIL PROTECTED] [4:00pm][/mnt/usr/lost+found] >> rm -rf * > > > > rm: #5558272: Directory not empty > > > > rm: #7018496: Directory not empty > > > > rm: #7206914: Directory not empty > > > > rm: #7254025: Directory not empty > > > > rm: #7254167: Directory not empty > > > > > > Unmount the filesystem and run fsck again (e.g. with the -f flag). > > > You seem to have additional filesystem corruption here. > > > > I did fsck with the -fy flag just now and this is what it says: > > > > UNREF DIR I=471104 OWNER=root MODE=40755 > > SIZE=512 MTIME=Mar 1 04:00 2004 > > RECONNECT? yes > > > > SORRY. NO SPACE IN lost+found DIRECTORY > > UNEXPECTED SOFT UPDATE INCONSISTENCY > > Is the disk full or out of inodes? Not sure about the inodes but the disk is at 0% capacity as ad2s1a doesn't have any problems. ad2s1d is the one where I rm -rf . since that is used to do a dump,restore of /usr. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] [EMAIL PROTECTED] - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: deleting lost+found directory
On Sat, Mar 06, 2004 at 03:53:13PM -1000, Vincent Poy wrote: > On Sat, 6 Mar 2004, Kris Kennaway wrote: > > > On Sat, Mar 06, 2004 at 02:00:12PM -1000, Vincent Poy wrote: > > > > > > They're just directories, remove them in the usual way. > > > > > > Tried that, didn't work... > > > > > [EMAIL PROTECTED] [4:00pm][/mnt/usr/lost+found] >> rm -rf * > > > rm: #5558272: Directory not empty > > > rm: #7018496: Directory not empty > > > rm: #7206914: Directory not empty > > > rm: #7254025: Directory not empty > > > rm: #7254167: Directory not empty > > > > Unmount the filesystem and run fsck again (e.g. with the -f flag). > > You seem to have additional filesystem corruption here. > > I did fsck with the -fy flag just now and this is what it says: > > UNREF DIR I=471104 OWNER=root MODE=40755 > SIZE=512 MTIME=Mar 1 04:00 2004 > RECONNECT? yes > > SORRY. NO SPACE IN lost+found DIRECTORY > UNEXPECTED SOFT UPDATE INCONSISTENCY Is the disk full or out of inodes? Kris pgp0.pgp Description: PGP signature
Re: deleting lost+found directory
On Sat, 6 Mar 2004, Kris Kennaway wrote: > On Sat, Mar 06, 2004 at 02:00:12PM -1000, Vincent Poy wrote: > > > > They're just directories, remove them in the usual way. > > > > Tried that, didn't work... > > > [EMAIL PROTECTED] [4:00pm][/mnt/usr/lost+found] >> rm -rf * > > rm: #5558272: Directory not empty > > rm: #7018496: Directory not empty > > rm: #7206914: Directory not empty > > rm: #7254025: Directory not empty > > rm: #7254167: Directory not empty > > Unmount the filesystem and run fsck again (e.g. with the -f flag). > You seem to have additional filesystem corruption here. I did fsck with the -fy flag just now and this is what it says: UNREF DIR I=471104 OWNER=root MODE=40755 SIZE=512 MTIME=Mar 1 04:00 2004 RECONNECT? yes SORRY. NO SPACE IN lost+found DIRECTORY UNEXPECTED SOFT UPDATE INCONSISTENCY Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] [EMAIL PROTECTED] - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: deleting lost+found directory
On Sat, Mar 06, 2004 at 02:00:12PM -1000, Vincent Poy wrote: > > They're just directories, remove them in the usual way. > > Tried that, didn't work... > [EMAIL PROTECTED] [4:00pm][/mnt/usr/lost+found] >> rm -rf * > rm: #5558272: Directory not empty > rm: #7018496: Directory not empty > rm: #7206914: Directory not empty > rm: #7254025: Directory not empty > rm: #7254167: Directory not empty Unmount the filesystem and run fsck again (e.g. with the -f flag). You seem to have additional filesystem corruption here. Kris pgp0.pgp Description: PGP signature
Re: deleting lost+found directory
On Sat, 6 Mar 2004, Kris Kennaway wrote: > On Sat, Mar 06, 2004 at 08:27:11AM -1000, Vincent Poy wrote: > > Hi everyone: > > > > On one of my disks that has no files in it mounted as /mnt/usr, > > fsck is creating the lost+found directory and underneath each one are > > directories named starting with # that is empty, is there anyway to remove > > these? Thanks. > > They're just directories, remove them in the usual way. Tried that, didn't work... [EMAIL PROTECTED] [4:00pm][/mnt/usr] >> cd lost+found [EMAIL PROTECTED] [4:00pm][/mnt/usr/lost+found] >> dir total 56 drwxr-xr-x 20 root wheel - 512 Mar 6 10:16 #5558272 drwxr-xr-x5 root wheel - 512 Mar 4 04:00 #7018496 drwxr-xr-x 108 root wheel - 8704 Mar 1 04:00 #7206914 drwxr-xr-x 43 root wheel - 1024 Mar 4 04:00 #7254025 drwxr-xr-x 118 root wheel - 2048 Mar 4 04:00 #7254167 drwx--7 root wheel - 35840 Mar 6 10:33 . drwxr-xr-x 49 root wheel - 512 Mar 5 20:43 .. [EMAIL PROTECTED] [4:00pm][/mnt/usr/lost+found] >> dir * #5558272: total 38 drwxr-xr-x 20 root wheel - 512 Mar 6 10:16 . drwx-- 7 root wheel - 35840 Mar 6 10:33 .. #7018496: total 38 drwxr-xr-x 5 root wheel - 512 Mar 4 04:00 . drwx-- 7 root wheel - 35840 Mar 6 10:33 .. #7206914: total 46 drwxr-xr-x 108 root wheel - 8704 Mar 1 04:00 . drwx--7 root wheel - 35840 Mar 6 10:33 .. #7254025: total 38 drwxr-xr-x 43 root wheel - 1024 Mar 4 04:00 . drwx-- 7 root wheel - 35840 Mar 6 10:33 .. #7254167: total 38 drwxr-xr-x 118 root wheel - 2048 Mar 4 04:00 . drwx--7 root wheel - 35840 Mar 6 10:33 .. [EMAIL PROTECTED] [4:00pm][/mnt/usr/lost+found] >> rm -rf * rm: #5558272: Directory not empty rm: #7018496: Directory not empty rm: #7206914: Directory not empty rm: #7254025: Directory not empty rm: #7254167: Directory not empty Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] [EMAIL PROTECTED] - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: deleting lost+found directory
On Sat, Mar 06, 2004 at 08:27:11AM -1000, Vincent Poy wrote: > Hi everyone: > > On one of my disks that has no files in it mounted as /mnt/usr, > fsck is creating the lost+found directory and underneath each one are > directories named starting with # that is empty, is there anyway to remove > these? Thanks. They're just directories, remove them in the usual way. Kris pgp0.pgp Description: PGP signature
deleting lost+found directory
Hi everyone: On one of my disks that has no files in it mounted as /mnt/usr, fsck is creating the lost+found directory and underneath each one are directories named starting with # that is empty, is there anyway to remove these? Thanks. [EMAIL PROTECTED] [10:26am][/mnt/usr/lost+found] >> dir total 56 drw-rw-rw- 20 root wheel - 512 Mar 6 10:16 #5558272 drwxr-xr-x5 root wheel - 512 Mar 4 04:00 #7018496 drwxrwxrwx 108 root wheel - 8704 Mar 1 04:00 #7206914 drwxr-xr-x 43 root wheel - 1024 Mar 4 04:00 #7254025 drwxr-xr-x 118 root wheel - 2048 Mar 4 04:00 #7254167 drwx--7 root wheel - 35840 Mar 6 10:16 . drwxr-xr-x 23 root wheel - 512 Mar 6 10:16 .. [EMAIL PROTECTED] [10:26am][/mnt/usr/lost+found] >> dir * #5558272: total 38 drw-rw-rw- 20 root wheel - 512 Mar 6 10:16 . drwx-- 7 root wheel - 35840 Mar 6 10:16 .. #7018496: total 38 drwxr-xr-x 5 root wheel - 512 Mar 4 04:00 . drwx-- 7 root wheel - 35840 Mar 6 10:16 .. #7206914: total 46 drwxrwxrwx 108 root wheel - 8704 Mar 1 04:00 . drwx--7 root wheel - 35840 Mar 6 10:16 .. #7254025: total 38 drwxr-xr-x 43 root wheel - 1024 Mar 4 04:00 . drwx-- 7 root wheel - 35840 Mar 6 10:16 .. #7254167: total 38 drwxr-xr-x 118 root wheel - 2048 Mar 4 04:00 . drwx--7 root wheel - 35840 Mar 6 10:16 .. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] [EMAIL PROTECTED] - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
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
Lost + Found
Hi, 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 ?? thanks Doron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
