[Jfs-discussion] JFS-Questions
Brought to you by:
blaschke-oss,
shaggyk
From: <mt...@am...> - 2003-09-17 06:57:47
|
Hello Jfs-discussion, I'm using JFS for quite a while and gained some experience to share for an estimation how critical (data-loss) the observed problems are. Systems used: i386 with SuSE 7.3, 8.0, 8.1 and 8.2 - deleted filespace (several gigs) is not made available - even after repetitive syncs - fsck-ing/remounting/reboot helped... problem: it required a system-reboot because it was the root-filesystem which was affected - partition was checked as clean on restart after crash - none the less the filesystem had errors. it required a manual and forced full JFS check to get rid of them. -> how reliable is the clean/dirty detection really and what could make it fail? - after a HD-sector-failure I was able to rescue most of the disk's sectors with dd_rescue - but not all sectors could be copied correctly. -> does JFS employ block/sector checksums in order to be able to detect integrity-errors (or is this possibe) - I was worried which files contained data from errorous sectors. Fortunately the system survived the failure quite well and no essential files seem to got damaged - nontheless I asked myself what would happen if it went worse - how could I detect which files were OK and which were not. - a friend of mine lost all data on one parition due to "invalid superblocks" - fsck.jfs printed this message and gave up... great - all sectors still contained valid files, data, etc... maybe it was some geometry offset due to changing hardware. -> this is what worries me most - is there a practical solution to recover data if the superblocks gets corrupted or slightly byte-offset (+/-1 errors) -> for example: is it possible to scan all sectors of the partition and (at least partially) reconstruct the filesystem? (when hex-looking at the partition-header it showed some "normal" looking JFS signature and following blocks) - a similar problem like the one above happened to me - a disk which I had formatted, set up and used in a removeable bay refused to mount when connected via external interface (firewire - but hex-dumping of sector contents worked fine!) - the disk mounted fine when it was placed back into the internal bay again... really weird! (Note: /etc/fstab entries were correct :)) Formatting the partition while hooked on firewire seems to have solved the problem. - fsck once "trashed" my home-directory and all files inside (suse 8.2) all files were renamed and dumped to lost+found... -> I don't know how this happened, but it was quite horrible to manually rename and move the files back! Fortunately for me the locate database was still holding the original names and structure - but it took quite long to inspect the contents. -> why the overhead of journaling when fsck won't recover the filenames... there should be a way to maintain more original information during fsck. Best regards! PS - my personal jfs-feature-whishlist: - shrinking - built-in encryption-layer (as loop-aes would render journaling useless - when included in the FS) |