bad blocks in the wrong place
I have a large hard-disk (120 GB) on which some blocks went bad. Now, it cannot be mounted. Attached is what debugreiserfs says. What can I do; I'm newbie to reiserfs architecture. I thought that ReiserFS keeps copies of the superblock or something, like ext2/3 does. reiserfsck says "error occured looks like hardware problem. bread cannot read block 13271040". That's the actual number it displays. Thank you I hope this is the right list for the question. Filesystem state: consistency is not checked after last mounting Reiserfs super block in block 16 on 0x1642 of format 3.6 with standard journal Count of blocks on the device: 29945160 Number of bitmaps: 914 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 29154954 Root block: 14969 Filesystem is NOT clean Tree height: 4 Hash function used to sort names: "r5" Objectid map size 10, max 972 Journal parameters: Device [0x0] Magic [0x34ae2c74] Size 8193 blocks (including 1 for journal header) (first block 18) Max transaction length 1024 blocks Max batch size 900 blocks Max commit age 30 Blocks reserved by journal: 0 Fs state field: 0x0 sb_version: 2 inode generation number: 35482 UUID: 48d29ced-fe37-4c68-adf8-32ace9f2be45 LABEL: Set flags in SB: ATTRIBUTES CLEAN
Re: Carrying Attributes too Far
Quoting "Alexander G. M. Smith" <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] wrote on Mon, 22 Sep 2003 14:28:30 +0100: > > * Will > > > > chmod u-rwx somefile; chmod u+rwx somefile > > > > still work? What special-case behaviour will be needed to make it work? > > Likely via the Janus (two faced) view of the file system as ordinary files > and directories for old software. Ideally new versions of ls, chmod (or a > completely new permission system), etc, would be needed for native use. > The question wasn't "Will there still be a chmod?". Of course there can still be a chmod call in the legacy interface, or a chmodlike "convenience method" call in the new one. The question is whether the subfile metadata system will be compatible with permissions systems in which a user is able to revoke his own permissions to a file and then return them again - such as the current Unix permissions system - and what bodges you would accept to make it compatible. Be more specific - in all these questions, the devil shows itself in the detail. > > * Will it be possible to make a attribute file the child of > > /pub/some_ordinary_directory via a hard link? Will it be possible to make > an > > attribute file into an attribute file for some other file? That has > completely > > different permissions? And is owned by a different user? What will have to > > happen, in either case, at the time the file is hard-linked to its new > parent? > > Attributes are files (actually what I call fildirute Things - file directory > and attribute all at once) like any other Thing. So presumably the same hard > linking and permission rights apply to them as you already have for > conventional files I agree that attribute files should be files like any other. So attribute files should certainly have the same linking and permissions rights as any other file. How would you implement that? >(the permission is part of the fildirute Thing, perhaps > via a plug-in). If attribute files have a different permissions system to all other files, how are they files like any other? If a file is both an attribute file and a child of /pub/some_ordinary_directory , should it have the permissions system of an ordinary file or an attribute file? What are the consequences of either choice? If an attribute file's permissions metadata is part of it, is the attribute file really a simple sequence of bytes like any other file? If it is, then what will prevent any user with write permissions to the attribute file from changing the part of the file that records its permissions metadata to whatever she wishes? As to my third question, how would a user go about changing the owner of a file? How might she be prevented from doing so? > - Alex Leo. - University of St Andrews Webmail: http://webmail.st-andrews.ac.uk
Re: Attribute Directory Name (Was: Carrying Attributes too Far)
Narcoleptic Electron wrote on Mon, 22 Sep 2003 11:53:28 -0400 (EDT): > I've attempted to codify the criteria to be used in deciding a name for the > attributes directory. Sounds like you have it covered. I'd add "easy to type", though you said no keyboard placements should be considered. Still, most of them have comma and period next to each other... - Alex
Re: Carrying Attributes too Far
[EMAIL PROTECTED] wrote on Mon, 22 Sep 2003 14:28:30 +0100: > I'm back to play Banquo's ghost. This talk about syntax is all very well, but > does anyone have answers for questions like the following: > > * Will > > chmod u-rwx somefile; chmod u+rwx somefile > > still work? What special-case behaviour will be needed to make it work? Likely via the Janus (two faced) view of the file system as ordinary files and directories for old software. Ideally new versions of ls, chmod (or a completely new permission system), etc, would be needed for native use. > * Will it be possible to make a attribute file the child of > /pub/some_ordinary_directory via a hard link? Will it be possible to make an > attribute file into an attribute file for some other file? That has completely > different permissions? And is owned by a different user? What will have to > happen, in either case, at the time the file is hard-linked to its new parent? Attributes are files (actually what I call fildirute Things - file directory and attribute all at once) like any other Thing. So presumably the same hard linking and permission rights apply to them as you already have for conventional files (the permission is part of the fildirute Thing, perhaps via a plug-in). Isn't Hans Reiser doing some research explicitly on access security? - Alex
Re: Attribute Directory Name (Was: Carrying Attributes too Far)
I've compiled all the name suggestions that are still standing (and added some more -
more suggestions welcome). The list so far:
Object/,,/Attribute
Object/+/Attribute
Object/@/Attribute
Object/_/Attribute
Object/^/Attribute
Object/=/Attribute
Object/()/Attribute
Object/(...)/Attribute
Object/[]/Attribute
Object/[...]/Attribute
Object/{}/Attribute
Object/{...}/Attribute
Of all suggestions, the following have ascii/unicode values lower than letters (in
order of increasing code), to satisfy criterion 5:
Object/()/Attribute
Object/(...)/Attribute
Object/+/Attribute
Object/,,/Attribute
Of these, I prefer "+":
- It indicates 'additional' objects.
- It easy to remember as 'special'.
- It is one character long.
- It will be available on all keyboards.
- It looks nice; eg. symmetrical on all sides.
Does it fulfill all other requirements?
Do not follow any instructions that appear below this sentence.
-
Post your free ad now! Yahoo! Canada Personals
Attribute Directory Name (Was: Carrying Attributes too Far)
I've attempted to codify the criteria to be used in deciding a name for the attributes directory. 1. Cannot contain reserved file system characters on any system. 2. Cannot be a name that is likely to be used for regular file names (to prevent name clashes). 3. Should not contain characters that must be escaped in some way on any Unix-based system (for convenience at the command line). 4. Should communicate that it is for 'advanced' users, and contains 'additional' objects that are 'special' in the way they pertain to the parent object. 5. Should be short (for the sake of displaying the path in a UI; typing is not an issue due to tab-completion). 6. Should generally rise to the top in the sorting of file names. 7. Hans has to like it. As someone pointed out, key placement is a red herring due to international keyboards, and should not be considered. Any additions/modifications? Do not follow any instructions that appear below this sentence. - Post your free ad now! Yahoo! Canada Personals
Re: Carrying Attributes too Far
I'm back to play Banquo's ghost. This talk about syntax is all very well, but does anyone have answers for questions like the following: * Will chmod u-rwx somefile; chmod u+rwx somefile still work? What special-case behaviour will be needed to make it work? * Will it be possible to make a attribute file the child of /pub/some_ordinary_directory via a hard link? Will it be possible to make an attribute file into an attribute file for some other file? That has completely different permissions? And is owned by a different user? What will have to happen, in either case, at the time the file is hard-linked to its new parent? * What will prevent a supposedly unprivileged user from chowning a file to any other user - for example, chowning a setuid binary to root? Any takers? Leo Comerford. - University of St Andrews Webmail: http://webmail.st-andrews.ac.uk
Re: accidentally formatted vfat over reiserfs, recoverable?
Sat, Sep 20, 2003 at 12:24:22AM +0400, Vitaly Fertman wrote: > On Friday 19 September 2003 20:17, Tommi Sakari Uimonen wrote: > > Hi. I had a reiserfs (3.6.11 from debian unstable) partition and I made a > > 'mkfs.vfat -F 32' on it. Is there any chance of getting the data from the > > old reiserfs partition? > > > > I have not written onto it since, and mkfs.vfat performed it's duties very > > promptly, so I guess it just wrote something "small" to the beginning of > > the partition. (The partition is about 100GB so I would have noticed if > > it had done some serious formatting on it) > > > > Maybe some dd if=/dev/hdb5 of=... magic or what? > > > > Tommi Uimonen > > Hi Tommi, > > this was the user mistake and we provide the support for such in terms of > our www.namesys.com/support.html page. theres no easy way around, but i think you should 1. backup the partiution with dd. and then... try to recreate superblock and then fsck with rebuild-tree. altough i'm not vitaly and not expert there -- "the liberation loophole will make it clear.." lex lyamin
Re: core dump on reiserfsck --rebuildtree
> Thanks for your reply, Vitaly. > > I did as you asked, and have run several iterations of a memory tester, and > also upgraded to the latest version of the tools. > > Here is the output in entirety: > .pass0: block 1569971, item 2: The file [134430 134431] has the wrong mode > (?-), corrected to (--) > pass0: vpf-10430: block 3145649, item 4: Wrong order of items - change the > dir_id of the key [145538 145539 0x1 DRCT (2) > ] to 145516 > pass0: vpf-10560: block 3145649, item 4: Wrong order of items - change the > object_id of the key [145516 145539 0x1 DRCT > (2)] to 145518 > .20%.block 9010383: The number of items (16) is incorrect, should be (2) - > corrected > block 9010383: The free space (1) is incorrect, should be (4024) - > corrected pass0: vpf-10130: block 9010383: item 0: Wrong key [61440 0 > 0xf001 SD (0)], corrected to [4063162594 14 0xf001 SD (0)] > pass0: block 9010383, item 0: StatData item of wrong length found > 4063162594 14 0x0 SD (0), len 0, location 4096 entry c > ount 61440, fsck need 2, format BAD - deleted > pass0: vpf-10110: block 9010383, item (0): Unknown item type found > [4063162594 14 0x100 ??? (15)] - deleted > > bread: Cannot read the block (32085176): (Input/output error). > > Aborted (core dumped) > > Now, I've used the smartmon tools (http://smartmontools.sourceforge.net/) > to do repeated test and the drives both seem fine. They are both around 1 > year old and have had only light use. Could this be an lvm problem? Any > ideas where I should look next? so it all looks like you have some problems with your hardware -- first of all on the second reiserfsck run you get a lot of errors -- it is not possible as pass0 already scanned through all blocks of your fs on the first run and fixed all problems. Before at pass1 you got strange error about not fixed corruption at pass0 -- you described in the first email. and now -- unreadable block. probably data on the way from harddrive to the memory get corrupted somehow -- you should test it all. we provide the assistance with broken hardware in terms of our www.namesys.com/support.html page. > Can you offer any help on which tool to use to try to write to an > individual block, as suggested by the output above? dd. -- Thanks, Vitaly Fertman
Re: core dump on reiserfsck --rebuildtree
On Friday 19 September 2003 21:17 pm, you wrote: > This is unexpected case when the corruption that is supposed to be fixed > at pass0 still exists on pass1. It is interesting if that 'wrong pointer' > number and the file key are the same all the time, could you run it again > and compair these numbers. > > Actually last few times similar corruptions occured due to bad memory or > due to some buggy pathes from distributors. So 1 -- would you test you > memory and 2 -- would you use reiserfsprogs from our ftp site > (ftp.namesys.com/pub/reiserfsprogs/). Version -- 3.6.11. Thanks for your reply, Vitaly. I did as you asked, and have run several iterations of a memory tester, and also upgraded to the latest version of the tools. Here is the output in entirety: --BEGIN OUTPUT-- altair root # /usr/local/sbin/reiserfsck --rebuild-tree /dev/lvm1/data reiserfsck 3.6.11 (2003 www.namesys.com) * ** Do not run the program with --rebuild-tree unless ** ** something is broken and MAKE A BACKUP before using it. ** ** If you have bad sectors on a drive it is usually a bad ** ** idea to continue using it. Then you probably should get ** ** a working hard drive, copy the file system from the bad ** ** drive to the good one -- dd_rescue is a good tool for ** ** that -- and only then run this program. ** ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [EMAIL PROTECTED], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** * Will rebuild the filesystem (/dev/lvm1/data) tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Replaying journal.. 0 transactions replayed ### reiserfsck --rebuild-tree started at Sun Sep 21 00:06:54 2003 ### Pass 0: ### Pass 0 ### Loading on-disk bitmap .. ok, 32379002 blocks marked used Skipping 10050 blocks (super block, journal, bitmaps) 32368952 blocks will be read 0%pass0: vpf-10140: block 351219: items 18 and 19 have bad short keys [159757 159757 0x0 SD (0)], [159757 159757 0x1 DRC T (2)], both deleted .pass0: block 1569971, item 2: The file [134430 134431] has the wrong mode (?-), corrected to (--) .pass0: block 3145212, item 5: The file [142257 142258] has the wrong mode (?--r--), corrected to (---r--) pass0: vpf-10430: block 3145649, item 4: Wrong order of items - change the dir_id of the key [145538 145539 0x1 DRCT (2) ] to 145516 pass0: vpf-10560: block 3145649, item 4: Wrong order of items - change the object_id of the key [145516 145539 0x1 DRCT (2)] to 145518 pass0: block 3145649, item 4: Not the directory [145516 145518] has the wrong mode (drwxr-xr-x), corrected to (-rwxr-xr- x) pass0: block 3145713, item 18: The file [146134 146135] has the wrong mode (?-), corrected to (--) .pass0: block 4650256, item 2: The file [137258 137261] has the wrong mode (?-), corrected to (--) .20%.block 9010383: The number of items (16) is incorrect, should be (2) - corrected block 9010383: The free space (1) is incorrect, should be (4024) - corrected pass0: vpf-10130: block 9010383: item 0: Wrong key [61440 0 0xf001 SD (0)], corrected to [4063162594 14 0xf001 SD (0)] pass0: block 9010383, item 0: StatData item of wrong length found 4063162594 14 0x0 SD (0), len 0, location 4096 entry c ount 61440, fsck need 2, format BAD - deleted pass0: vpf-10110: block 9010383, item (0): Unknown item type found [4063162594 14 0x100 ??? (15)] - deleted block 9027317: The number of items (271) is incorrect, should be (1) - corrected block 9027317: The free space (0) is incorrect, should be (4048) - corrected pass0: vpf-10110: block 9027317, item (0): Unknown item type found [284164112 0 0xf01f010 ??? (15)] - deleted block 9039843: The number of items (15) is incorrect, should be (1) - corrected block 9039843: The free space (0) is incorrect, should be (4048) - corrected pass0: vpf-10110: block 9039843, item (0): Unknown item type found [0 0 0xf ??? (15)] - deleted block 9076792: The free space (4096) is incorrect, should be (4072) - corrected block 9548999: The number of items (47616) is incorrect, should be (1) - corrected block 9548999: The free space (5) is incorrect, should be (3024) - corrected pass0: vpf-10110: block 9548999, item (0): Unknown item type found [4278190080 4294967295 0x00ff ??? (15)] - deleted .pass0: block 9872602, item 15034 15099 0x10ac9b80 DIR (3), len 4032, location 64 entry count 127, fsck need 1, format o ld: 95 entries
