April 17, 200818 yr Hi, I assume I'm missing something fundamental and trivial, but I'm completely stuck and hoping that someone here can set me straight. I'm using a 400 GB cache drive and six (5 + 1) 1 TB drives on my unRAID server. For some reason, data cannot be moved from the cache drive to the array. When I click "Move Now", a few thousand reads are performed on the cache drive and on the first HDD in the array (which has over 500 GB of free space), then nothing happens. User shares are enabled and split levels are set to 2 on all shares. Export Mode is Read/Write both on User and Disk Levels. Furthermore, the cache is now full, and there is no overflow directly to the array. i.e. It is not possible to copy files directly to the array. I just get an error message that "Disk is full" although there are a couple of empty Terabytes on the array. This is irrespective of whether trying to access User Shares or Disk Shares. Any ideas? Cheers!
April 17, 200818 yr Any chance there is a folder in the paths used that begins with a period? How deep in the paths are these copies?
April 17, 200818 yr syslog? http://lime-technology.com/wiki/index.php?title=Troubleshooting#Capturing_your_syslog
April 18, 200818 yr Author Any chance there is a folder in the paths used that begins with a period? How deep in the paths are these copies? Actually, on the cache disk there were a number of files and folders beginning with a period, all several levels down in the paths. After deleting these, some 60 GB could be moved from the cache to the array before things ground to a halt again. Unfortunately, I forgot to save a copy of the syslog for this session before re-booting. Presently, there are no folders or files on the cache disk beginning with a period. There are no folders on the array beginning with a period, but many files that do. I attach a more recent syslog. Below is an excerpt, showing the move attempts. # Manual "Move Now" Apr 17 21:22:41 TowerWAV emhttp: shcmd (25): /usr/local/sbin/mover | logger 2>&1 & Apr 17 21:22:41 TowerWAV logger: mover started Apr 17 21:23:09 TowerWAV shfs(1): duplicate object: /mnt/disk1/Video/000_Documentaries/zzz.avi # Some 30 duplicates are listed Apr 17 21:24:39 TowerWAV logger: `./Video/000_Documentaries/Something/Something.S01E01.avi' -> `/mnt/user0/./Video/000_Documentaries/Something/Something.S01E01.avi' # and so on...556 similar entries Apr 17 21:24:55 TowerWAV logger: mover finished # Nothing moved # Automatic move Apr 18 03:40:01 TowerWAV logger: mover started Apr 18 03:41:08 TowerWAV logger: `./Video/000_Documentaries/Something/Something.S01E01.avi' -> `/mnt/user0/./Video/000_Documentaries/Something/Something.S01E01.avi' # 556 similar entries Apr 18 03:42:04 TowerWAV logger: mover finished Apr 18 03:42:06 TowerWAV crond[3599]: unable to exec /usr/sbin/sendmail -t, user -oem, output to sink null # Nothing moved # Manual "Move Now" Apr 18 08:48:50 TowerWAV emhttp: shcmd (26): /usr/local/sbin/mover | logger 2>&1 & Apr 18 08:48:50 TowerWAV logger: mover started Apr 18 08:49:15 TowerWAV logger: `./Video/000_Documentaries/Something/Something.S01E01.avi' -> `/mnt/user0/./Video/000_Documentaries/Something/Something.S01E01.avi' # 556 similar entries Apr 18 08:50:01 TowerWAV logger: mover finished # Nothing moved I'm clueless, so any input is appreciated. Cheers!
April 18, 200818 yr It doesn't matter that the files/folders in the Video share start with a '.' - this only matters for top-level directories on disks. For example, suppose you have this: /mnt/disk1/Video <- a directory /mnt/disk1/.mydir <- a directory /mnt/disk1/myfile <- a file The 'Video' folder will be considered a user share, but the '.mydir' folder will not because it starts with a '.' and 'myfile' will not be a user share because it's a file. At all other levels, a leading '.' in either a directory name or file name is irrelevant. For your 'Video' share do you have anything set in the 'Included disks/Excluded disks' share settings? Also, please post unedited syslog or email to me: [email protected]
April 18, 200818 yr Author It doesn't matter that the files/folders in the Video share start with a '.' - this only matters for top-level directories on disks. For example, suppose you have this: /mnt/disk1/Video <- a directory /mnt/disk1/.mydir <- a directory /mnt/disk1/myfile <- a file The 'Video' folder will be considered a user share, but the '.mydir' folder will not because it starts with a '.' and 'myfile' will not be a user share because it's a file. At all other levels, a leading '.' in either a directory name or file name is irrelevant. i.e. as it should be. Thanks for the clarification. For your 'Video' share do you have anything set in the 'Included disks/Excluded disks' share settings? Nope. Also, please post unedited syslog or email to me: [email protected] Done
April 21, 200818 yr Author Hi, Well, I'm still clueless as to what I'm doing wrong. I can't even write to the array. I've tried the following: 1. Set one of the user shares back to not using the cache, but I still get the message that the disk is full. 2. Create a new user share, not using the cache. Same thing, can't write, disk is full. 3. Re-boot without the cache disk. Same thing. When running without the cahe disk, I noticed several files w 0 bytes file size, i.e. the files on the cache disk were still shown. Is this the way it's supposed to be? Cheers!
April 21, 200818 yr Author Well, changing from High Water to Most Free seems to have "unlocked" the array. Writing and moving to the array now works again. But why? Any thoughts? Cheers!
April 22, 200818 yr Author Hi, unfortunately, changing from High Water to Most Free, only provided temporary relief. After moving some 100 GB, everything is "blocked" again. Not possible to move or write to the array. In addition, a number of parity errors have now occurred and the syslog shows what I assume to be hardware errors. Apr 21 19:50:55 TowerWAV kernel: ata4.00: cmd 60/c8:00:e7:bd:2c/03:00:70:00:00/40 tag 0 ncq 495616 in Apr 21 19:50:55 TowerWAV kernel: res 41/40:c8:e7:bd:2c/92:03:70:00:00/40 Emask 0x409 (media error) <F> Apr 21 19:50:55 TowerWAV kernel: ata4.00: status: { DRDY ERR } Apr 21 19:50:55 TowerWAV kernel: ata4.00: error: { UNC } Apr 21 19:50:55 TowerWAV kernel: ata4.00: configured for UDMA/133 Apr 21 19:50:55 TowerWAV kernel: sd 4:0:0:0: [sdc] Result: hostbyte=0x00 driverbyte=0x08 Apr 21 19:50:55 TowerWAV kernel: sd 4:0:0:0: [sdc] Sense Key : 0x3 [current] [descriptor] Apr 21 19:50:55 TowerWAV kernel: Descriptor sense data with sense descriptors (in hex): Apr 21 19:50:55 TowerWAV kernel: 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 Apr 21 19:50:55 TowerWAV kernel: 00 00 00 e7 Apr 21 19:50:55 TowerWAV kernel: sd 4:0:0:0: [sdc] ASC=0x11 ASCQ=0x4 Apr 21 19:50:55 TowerWAV kernel: end_request: I/O error, dev sdc, sector 1881980391 Apr 21 19:50:55 TowerWAV kernel: ata4: EH complete Apr 21 19:50:55 TowerWAV kernel: md0: read error! Apr 21 19:50:55 TowerWAV kernel: handle_stripe read error: 1881980328/0, count: 1 Apr 21 19:50:55 TowerWAV kernel: md0: read error! Apr 21 19:50:55 TowerWAV kernel: handle_stripe read error: 1881980336/0, count: 1 Apr 21 19:50:55 TowerWAV kernel: md0: read error! Clearly, I am lost and clueless, and any input, thoughts, guidance or help would be greatly appreciated. Cheers!
April 22, 200818 yr Some comments, derived from your syslog: Of first importance are the media errors on your parity drive sdc. The large blocks of read errors appear to result from the media errors discovered. They appear to be somewhat scattered, sectors 1881980391, 1881988559, 1882010903, 1887721895, 1826997415, 1761898775, 1761914407, 1761915423, 1761975439, 1761976175, 1761976463, 1761976175 (a repeat). That is, 3 sectors are around the 940GB point, a sector around the 920GB point, and the rest around 880GB. This is obviously troubling, as you would normally expect the SMART system to have handled these, but it apparently did not, or perhaps has already used up all of its spares. I think that a SMART report, and a SMART long disk test of your parity drive are imperative. As a side note, of interest to others, is a web page I found concerning this exact exception Emask (media error). It mentions a tool within the hdparm tarball, that will directly test a specific sector, by sector number. Someone would need to compile it for us, if it seems useful. http://lkml.org/lkml/2008/1/28/275 Interestingly (but not a real problem), your Disk 1 has been limited to a slightly smaller size than the other terabyte drives. On setup, it includes the following line: HPA detected: current 1953523055, native 1953525168 That indicates a deficit of 2113 512-byte sectors, or a loss of just over a megabyte, a loss of a millionth of the drive. It is not particularly significant, but seemed noteworthy. HPA stands for Host Protected Area, which something has installed on this drive, as a way of securing or hiding something.
April 22, 200818 yr directly test a specific sector, by sector number. Someone would need to compile it for us, I have not tested this. It is the latest version of the hdparm command itself. 8.6 If we get a good test out of this, (who has a bad drive and is brave?) Then I'll prepare a slackware installable package. Right now I'll just post the bin. Here is the help screen Šroot@slacky:/home/rcotrone/src/hdparm# ./hdparm hdparm - get/set hard disk parameters - version v8.6 Usage: hdparm [options] [device] .. Options: -a get/set fs readahead -A get/set the drive look-ahead flag (0/1) -b get/set bus state (0 == off, 1 == on, 2 == tristate) -B set Advanced Power Management setting (1-255) -c get/set IDE 32-bit IO setting -C check drive power mode status -d get/set using_dma flag -D enable/disable drive defect management -E set cd-rom drive speed -f flush buffer cache for device on exit -F flush drive write cache -g display drive geometry -h display terse usage information -H read temperature from drive (Hitachi only) -i display drive identification -I detailed/current information directly from drive -k get/set keep_settings_over_reset flag (0/1) -K set drive keep_features_over_reset flag (0/1) -L set drive doorlock (0/1) (removable harddisks only) -M get/set acoustic management (0-254, 128: quiet, 254: fast) -m get/set multiple sector count -N get/set max visible number of sectors (HPA) (VERY DANGEROUS) -n get/set ignore-write-errors flag (0/1) -p set PIO mode on IDE interface chipset (0,1,2,3,4,...) -P set drive prefetch count -q change next setting quietly -Q get/set DMA tagged-queuing depth (if supported) -r get/set device readonly flag (DANGEROUS to set) -R register an IDE interface (DANGEROUS) -s set power-up in standby flag (0/1) (DANGEROUS) -S set standby (spindown) timeout -t perform device read timings -T perform cache read timings -u get/set unmaskirq flag (0/1) -U un-register an IDE interface (DANGEROUS) -v defaults; same as -acdgkmur for IDE drives -V display program version and exit immediately -w perform device reset (DANGEROUS) -W get/set drive write-caching flag (0/1) -x tristate device for hotswap (0/1) (DANGEROUS) -X set IDE xfer mode (DANGEROUS) -y put drive in standby mode -Y put drive to sleep -Z disable Seagate auto-powersaving mode -z re-read partition table --direct use O_DIRECT to bypass page cache for timings --drq-hsm-error crash system with a "stuck DRQ" error (VERY DANGEROUS) --Istdin read identify data from stdin as ASCII hex --Istdout write identify data to stdout as ASCII hex --make-bad-sector deliberately corrupt a sector directly on the media (VERY DANGEROUS) --read-sector read and dump (in hex) a sector directly from the media --security-help display help for ATA security commands --verbose display extra diagnostics from some commands --write-sector repair/overwrite a (possibly bad) sector directly on the media (VERY DANGEROUS) --make-bad-sector Deliberately create a bad sector (aka. "media error") on the disk. EXCEPTIONALLY DANGEROUS. DO NOT USE THIS FLAG!! This can be useful for testing of device/RAID error recovery mecha- nisms. The sector number is given as a (base10) parameter after the flag. Depending on the device, hdparm will choose one of two possible ATA commands for corrupting the sector. The WRITE_LONG works on most drives, but only up to the 28-bit sec- tor boundary. Some very recent drives (2008) may support the new WRITE_UNCORRECTABLE_EXT command, which works for any LBA48 sector. If available, hdparm will use that in preference to WRITE_LONG. The WRITE_UNCORRECTABLE_EXT command itself presents a choice of how the new bad sector should behave. By default, it will look like any other bad sector, and the drive may take some time to retry and fail on subsequent READs of the sector. However, if a single letter f is prepended immediately in front of the first digit of the sector number parameter, then hdparm will issue a "flagged" WRITE_UNCORRECTABLE_EXT, which causes the drive to merely flag the sector as bad (rather than genuinely corrupt it), and subsequent READs of the sector will fail imme- diately (rather than after several retries). Note also that the --repair-sector flag can be used to restore (any) bad sectors when they are no longer needed, including sectors that were gen- uinely bad (the drive will likely remap those to a fresh area on the media). --read-sector Reads from the specified sector number, and dumps the contents in hex to standard output. The sector number must be given (base10) after this flag. hdparm will issue a low-level read (completely bypassing the usual block layer read/write mecha- nisms) for the specified sector. This can be used to defini- tively check whether a given sector is bad (media error) or not (doing so through the usual mechanisms can sometimes give false positives). --repair-sector This is an alias for the --write-sector flag. VERY DANGEROUS. --write-sector Writes zeros to the specified sector number. VERY DANGEROUS. The sector number must be given (base10) after this flag. hdparm will issue a low-level write (completely bypassing the usual block layer read/write mechanisms) to the specified sec- tor. This can be used to force a drive to repair a bad sector (media error). See Also: http://lkml.org/lkml/2008/1/28/275 Keep in mind use of the special flags: when using --read-sector... If it reports an I/O error consistently on that, then the sector is indeed faulty, and it's contents have long been lost. You can repair the bad sector (but not the original contents) like this: make_bad_sector --rewrite /dev/sda 474507 (substitute with hdparm instead of make_bad_sector). Note that the contents of the sector are now zeroed out. High level formats will be affected. I'm not sure if resierfs is affected. Programs like badblocks can read and test sectors non destructively. That's what spinrite does.
April 22, 200818 yr Thanks WeeboTech for posting this. Your technical posts are awesome! It seems like a very powerful tool, but very dangerous at the same time. I'd definitely want to scrutinize my command before hitting enter!! I did have a couple questions: Is "make_bad_sector" a parameter to hdparm, or a stand-alone executable? (I didn't see the "--rewrite" parameter explained in the man page.) Will you include "badblock" when you create the package? I am a Spinrite user, but recently have been dissapointed with its support of larger drives (500G+). Not surprising since there has not been even a service update for years. I'd love to find something that does what it does with larger drives. Maybe badblock is the answer. But for a bad sector in an unRAID array, you want to let unRAID remap the sector. It will use the redundancy of the array to reconstitute the bad sector contents (whether it is on parity or on a data drive), and truely fix the error (i.e., rewrite the data so that SMART remaps the sector). So even with a bunch of bad sectors, unRAID should be able to fix things up with a parity check. This doesn't asnwer the question of why the sectors were bad in the first place, but if you get a new disk with bad sectors, even if they aren't detected right away, unRAID will find and correct (remap) the sectors without losing data. So theoretically you could take a random disk known to have a number of bad sectors on it, add it to your array, and use it without any consequence. The only sign of a problem would be some "errors" in the Web interface, indicating bad sectors that had been corrected. Although this is not what I would do, it gives you a sence of how well unRAID protects your data. I'm not sure if you ran "hdparm" or "make_bad_sector" to manually remap sectors, whether unRAID would "see" the operation or not. If not, I'd use it only after giving unRAID a chance to correct it through a few parity check cycles. Besides SpinRite, I have used a DOS tool called "HDD Regenerator" which tests a hard dirve, but it is horribly slow compared to Spinrite (like 1/100th the speed if I remember right). But it will take a parameter of the starting sector. When it finds a bad sector, it rewrites it so that SMART remaps the sector. I once had a bad sector that Spinrite found but it got stuck on and would not remap. I used HDD Regenerator and started it just before the bad sector. It remapped it instantly. So HDD Regenerator is good if you know the bad sector number, but takes FOREVER (many days) to test a big drive. HDD Regenerator has one other nice feature, when it remaps, it writes some specific string to the reconstructed sector (I forget what it is but something like "HDD REGENERATOR HDD REGENERATOR ..."). You could then do a data search inside your OS on that string and figure out what file was corrupted. Better than binary 0s IMO. Not sure if this is relevant to this discussion of bad sectors, but I once did a stupid thing and assigned a data disk to the parity slot while having no other disks assigned to the array. unRAID started writing to the disk at high speed. I realized it and hit the big red switch to stop the carnage, but the act of killing the power during the parity writing fenzy caused physical damage to a few sectors on the surface of the disk. Spinrite found and corrected the bad sectors (it wasn't a huge disk so Spinrite worked), which allowed me to recover data form the disk. The drive has worked fine since. I've never had this happen before - but this is one way bad sectors can develop!
April 22, 200818 yr Is "make_bad_sector" a parameter to hdparm, or a stand-alone executable? (I didn't see the "--rewrite" parameter explained in the man page.) Will you include "badblock" when you create the package? make_bad_sector is a standalone program in the contrib area of the source. It has to be compiled by hand. After I compiled and started testing in a minor way, I realized that the functionality had been merged directly into hdparm itself. So I recompiled the latest hdparm and posted that. I'll remake the hdparm as an installable package. Keep in mind, If you run hdparm on the /dev/sd? device, then you are bypassing the unraid/md layer totally. I do not know what the effects of this are. As far as badblocks, It seems to already be within unraid. The trick is learning how to position the starting sector. root@unraid:~# badblocks Usage: badblocks [-b block_size] [-i input_file] [-o output_file] [-svwnf] [-c blocks_at_once] [-p num_passes] [-t test_pattern [-t test_pattern [...]]] device [last_block [start_block]] rcotrone@gatekeeper ~> ssh slacky man badblocks rcotrone@slacky's password: unraidrocks BADBLOCKS( BADBLOCKS( NAME badblocks - search a device for bad blocks SYNOPSIS badblocks [ -svwnf ] [ -b block-size ] [ -c blocks_at_once ] [ -i input_file ] [ -o output_file ] [ -p num_passes ] [ -t test_pattern ] device [ last-block ] [ start-block ] DESCRIPTION badblocks is used to search for bad blocks on a device (usually a disk partition). device is the special file corresponding to the device (e.g /dev/hdc1). last-block is the last block to be checked; if it is not specified, the last block on the device is used as a default. start-block is an optional parameter specifying the starting block num- ber for the test, which allows the testing to start in the middle of the disk. If it is not specified the first block on the disk is used as a default. Important note: If the output of badblocks is going to be fed to the e2fsck or mke2fs programs, it is important that the block size is prop- erly specified, since the block numbers which are generated are very dependent on the block size in use by the filesystem. For this reason, it is strongly recommended that users not run badblocks directly, but rather use the -c option of the e2fsck and mke2fs programs. OPTIONS -b block-size Specify the size of blocks in bytes. The default is 1024. -c number of blocks is the number of blocks which are tested at a time. The default is 64. -f Normally, badblocks will refuse to do a read/write or a non- destructive test on a device which is mounted, since either can cause the system to potentially crash and/or damage the filesys- tem even if it is mounted read-only. This can be overridden using the -f flag, but should almost never be used --- if you think you're smarter than the badblocks program, you almost cer- tainly aren't. The only time when this option might be safe to use is if the /etc/mtab file is incorrect, and the device really isn't mounted. -i input_file Read a list of already existing known bad blocks. Badblocks will skip testing these blocks since they are known to be bad. If input_file is specified as "-", the list will be read from the standard input. Blocks listed in this list will be omitted from the list of new bad blocks produced on the standard output or in the output file. The -b option of dumpe2fs( can be used to retrieve the list of blocks currently marked bad on an exist- ing filesystem, in a format suitable for use with this option. -o output_file Write the list of bad blocks to the specified file. Without this option, badblocks displays the list on its standard output. The format of this file is suitable for use by the -l option in e2fsck( or mke2fs(. -p num_passes Repeat scanning the disk until there are no new blocks discov- ered in num_passes consecutive scans of the disk. Default is 0, meaning badblocks will exit after the first pass. -t test_pattern Specify a test pattern to be read (and written) to disk blocks. The test_pattern may either be a numeric value between 0 and ULONG_MAX-1 inclusive, or the word "random", which specifies that the block should be filled with a random bit pattern. For read/write (-w) and non-destructive (-n) modes, one or more test patterns may be specified by specifying the -t option for each test pattern desired. For read-only mode only a single pattern may be specified and it may not be "random". Read-only testing with a pattern assumes that the specified pattern has previously been written to the disk - if not, large numbers of blocks will fail verification. If multiple patterns are specified then all blocks will be tested with one pattern before proceeding to the next pattern. -n Use non-destructive read-write mode. By default only a non- destructive read-only test is done. This option must not be combined with the -w option, as they are mutually exclusive. -s Show the progress of the scan by writing out the block numbers as they are checked. -v Verbose mode. -w Use write-mode test. With this option, badblocks scans for bad blocks by writing some patterns (0xaa, 0x55, 0xff, 0x00) on every block of the device, reading every block and comparing the contents. This option may not be combined with the -n option, as they are mutually exclusive. WARNING Never use the -w option on a device containing an existing file system. This option erases data! If you want to do write-mode testing on an existing file system, use the -n option instead. It is slower, but it will preserve your data. AUTHOR badblocks was written by Remy Card <[email protected]>. Current maintainer is Theodore Ts'o <[email protected]>. Non-destructive read/write test implemented by David Beattie <[email protected]>. AVAILABILITY badblocks is part of the e2fsprogs package and is available from http://e2fsprogs.sourceforge.net. SEE ALSO e2fsck(, mke2fs( E2fsprogs version 1.39 May 2006 BADBLOCKS(
April 28, 200818 yr KeithUR- I believe this problem will be fixed if you set 'split level' to 3. This will let the 'avi' files get allocated to another disk when it's parent directory gets full. A simplified example. Suppose you have 2 disks allocated to a share using 'high water' allocation. Now suppose you start filling up the share. Say you have this: /video/tv/lost/episode1 /video/tv/lost/episode2 etc. With split level at 2, at the time you first created the 'lost' folder, the system chose a disk for it, say disk1. From that point on, all files created under the '/video/tv/lost' directory will stay on disk1 (because such files will be at level 3). This is good and bad - good because as you go from episode to episode viewing Lost, then since they're all on the same disk there will be no disk spin up delay between episodes. But bad because if disk1 fills up, the 'lost' directory will not spill over to disk2 and you can't copy any more files to the '/video/tv/lost' directory. In your particular case, you probably don't care if there is a spin-up delay between episodes (but you probably would care if there was a spin-up delay between VOB files of a single movie). Hence I think you can set your split level to 3 and be happy with the result. BTW, there is a bug which is preventing 'disk full' error message generated by the mover from getting into the syslog - this is fixed in the next release.
June 6, 200818 yr Author Hi, thanks to everyone for all the input since I last visited this forum AND my unRAID server. I've just taken a new crack at this, and might have gotten it sorted. Touch wood. 1. I replaced the potentially dodgy parity disk - although later syslogs did not produce the media errors noted earlier. 2. I replaced disk1 None of this helped. Still got "Disk Full" although several Terabytes of free space. 3. I changed "Split Level" to 3, 4, and 5 respectively and subsequently. Did not help. 4. I did a "reiserfsck", which found several errors. After running "reiserfsck --rebuild-tree /dev/md1" things appear to be working and I can write to the array again. I note that I now have a new directory, "lost+found" with a large number of files and sub-directories. Not sure what to do with this... To my novice eyes, the syslog looks "normal", but I attach it just in case. Cheers!
June 6, 200818 yr Syslog looks great! As to your new "lost+found" folder, that is something that unfortunately only you can sort out, as you find time, recovering a file at a time. As I have never seen one personally, I am curious as to the 'quality' of the contents. Do they appear to be intact files with correct filenames, accurate file sizes and modification dates, and wholly intact content, correctly ordered from beginning to end? Or are they similar to those worst-case chunks of content that Windows produces, called Found.000 and up?
June 6, 200818 yr Syslog looks great! As to your new "lost+found" folder, that is something that unfortunately only you can sort out, as you find time, recovering a file at a time. As I have never seen one personally, I am curious as to the 'quality' of the contents. Do they appear to be intact files with correct filenames, accurate file sizes and modification dates, and wholly intact content, correctly ordered from beginning to end? Or are they similar to those worst-case chunks of content that Windows produces, called Found.000 and up? When you "fix" a file-system, any folders, files, or parts of files, that were not able to be reached from the broken file-system are put into a folder called lost+found. Most time, this is junk, but it might be a critical file. You should go through the pieces and files there to ensure nothing is important. Once you do, you can delete them.
June 6, 200818 yr Or are they similar to those worst-case chunks of content that Windows produces, called Found.000 and up? This is usually the case. Sometimes they are whole files which can be identified by reviewing them.
June 6, 200818 yr Author I am curious as to the 'quality' of the contents. Do they appear to be intact files with correct filenames, accurate file sizes and modification dates, and wholly intact content, correctly ordered from beginning to end? In my case, it's a mixed bag - there are a few hundred folders, which in some cases contain recognisable files. In addition, there are several thousand files with names like "1008_1014" with no extensions. These files vary in size from a few thousand kB to a couple of GB. Not sure I'll bother diving deeper into lost+found at the moment. After formatting two full 1 TB drives by mistake, I've gotten remarkably relaxed about data loss... Cheers!
June 6, 200818 yr After formatting two full 1 TB drives by mistake, I've gotten remarkably relaxed about data loss... YIKES!!! I mean WOW!!! I'd be somewhat reluctant to put you in charge of any data around my house for awhile! In fact, I would probably be following you around, telling you to "Step away from the computer"!
Archived
This topic is now archived and is closed to further replies.