SeventyDolllars for C0relDrawAndMore
www.6vslr56ush6v37o.wisnjwis7.com
Re: Reiserfs 1300G partition on lvm problem ...
Hi, Thanx for your reply. The data is not THAT importend, all our importend data is backuped 4 times, inc. original (well, 3 times now, since the 1300gig machine is broke). I did a bit furtur reasearch and maybe this is something to think about if you use reiserfs : I did a bad block check and I have 10 bad blocks of 4096bytes on 1300Gig and ... that is the reason reiserfs will not work anymore. I guess this sux. I rather have that the data on the bad blocks is just corupted but the rest is accesseble. I'm doing a --rebuild-tree with the bad block list. Hopes this works. Aren't there any tools to substract data from a broken reiserfs partition ? kind regardes, Matthias. [EMAIL PROTECTED] wrote: On Sun, 29 May 2005 21:25:54 +0200, Matthias Barremaecker said: but that sais it is a fysical drive error Physical drive errors. Your hardware is broken. Isn't much that Reiserfs can do about it. What can I do. 1) Call whoever you get hardware support from. 2) Be ready to restore from backups. 3) If you didn't have RAID-5 (or similar) set up, or a good backup, consider it a learning experience. If your data is important enough that you'll care if you lose it, you should take steps to make sure you won't lose it... It's that simple. (Just for the record, if we have important info, it gets at least RAID5, a backup to tape or other device, *and* a *second* backup off-site. And my shop is far from the most paranoid about such things.) -- Matthias Barremaecker, MH.BE - Arta nv 0495 30 31 72 http://mh.be/ SERVER HOUSING per 1HE € 50 per maand 20Gig traffic, 100Mbit netwerk Center te Antwerpen.
Re: Reiserfs 1300G partition on lvm problem ...
On Sun, 29 May 2005 21:25:54 +0200, Matthias Barremaecker said: > but that sais it is a fysical drive error Physical drive errors. Your hardware is broken. Isn't much that Reiserfs can do about it. > What can I do. 1) Call whoever you get hardware support from. 2) Be ready to restore from backups. 3) If you didn't have RAID-5 (or similar) set up, or a good backup, consider it a learning experience. If your data is important enough that you'll care if you lose it, you should take steps to make sure you won't lose it... It's that simple. (Just for the record, if we have important info, it gets at least RAID5, a backup to tape or other device, *and* a *second* backup off-site. And my shop is far from the most paranoid about such things.) pgp2dVSpWxCvh.pgp Description: PGP signature
World first Patch Technology for penis Enlargement
Finally a Patch that works! http://www.jnaz.net/ss/ How should they answer? Don't fear change, embrace it. Although prepared for martyrdom, I preferred that it be postponed. Start every day off with a smile and get it over with. Rumor travels faster, but it don't stay put as long as truth.
Reiserfs 1300G partition on lvm problem ...
Hi, I have a huge problem. setup : LVM with 8 disks fs : reiserfs All of the sudden it stoped working, I can't mount it anymore. reiserfsck said it had 43 errors and I should do reiserfsck --rebuild-tree what I did. but that sais it is a fysical drive error Point is : it is 1300 gig. and I can't mount it. What can I do. Thanx.
RE: Problems with accessing directory
Valdis, Thank you for your info, Its Sunday evening in Belgium, we will have to find a solution Because as ISP its that or cut the phone lines tomorrow :-) If we find something we'll post it Thanks, Kurt & Pascal -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Verzonden: zondag 29 mei 2005 20:05 Aan: Kurt Ghekiere CC: Webservice; reiserfs-list@namesys.com Onderwerp: Re: Problems with accessing directory On Sun, 29 May 2005 18:44:02 +0200, Kurt Ghekiere said: > May 29 17:28:51 mail3 kernel: Process hax0r (pid: 3738, > stackpage=f121b000) > May 29 17:28:51 mail3 kernel: Stack: bfe5 1000 > f63b6000 bfffe7f0 f63b6000 b8e4 > May 29 17:28:51 mail3 kernel:f78aaf22 0a3a 0020 f121a000 > c0108a93 000b bfffe7f0 f78a99a1 > May 29 17:28:51 mail3 kernel: > > May 29 17:28:51 mail3 kernel: Call Trace:[] > May 29 17:28:51 mail3 kernel: > May 29 17:28:51 mail3 kernel: Code: 8a 02 84 c0 75 ef e8 9c ec ff ff > 89 > c2 80 3a 00 0f 84 bb 00 Interesting process name indeed. Hopefully you recognize it? ;) I would suggest running the call trace through ksymoops, but it's so short that we've quite obviously clobbered the stack to the point that ksymoops won't tell us anything useful. I'd investigate why you get all those insmod errors - why is the system trying to load pciehp and hw_random if there's no device? Alternatively, are other modules getting loaded incorrectly and blocking those from starting? It's possible that if your kernel and modules are out of sync, that Bad Things like panics happen You probably should look at upgrading the userspace reiserfsck and MD/LVM tools - your kernel seems unhappy with the old versions. Other than that, I admit to not having any clear "AHA! THAT's their problem" solution, sorry
Re: Problems with accessing directory
On Sun, 29 May 2005 18:44:02 +0200, Kurt Ghekiere said: > May 29 17:28:51 mail3 kernel: Process hax0r (pid: 3738, > stackpage=f121b000) > May 29 17:28:51 mail3 kernel: Stack: bfe5 1000 f63b6000 > bfffe7f0 f63b6000 b8e4 > May 29 17:28:51 mail3 kernel:f78aaf22 0a3a 0020 f121a000 > c0108a93 000b bfffe7f0 f78a99a1 > May 29 17:28:51 mail3 kernel: > > May 29 17:28:51 mail3 kernel: Call Trace:[] > May 29 17:28:51 mail3 kernel: > May 29 17:28:51 mail3 kernel: Code: 8a 02 84 c0 75 ef e8 9c ec ff ff 89 > c2 80 3a 00 0f 84 bb 00 Interesting process name indeed. Hopefully you recognize it? ;) I would suggest running the call trace through ksymoops, but it's so short that we've quite obviously clobbered the stack to the point that ksymoops won't tell us anything useful. I'd investigate why you get all those insmod errors - why is the system trying to load pciehp and hw_random if there's no device? Alternatively, are other modules getting loaded incorrectly and blocking those from starting? It's possible that if your kernel and modules are out of sync, that Bad Things like panics happen You probably should look at upgrading the userspace reiserfsck and MD/LVM tools - your kernel seems unhappy with the old versions. Other than that, I admit to not having any clear "AHA! THAT's their problem" solution, sorry pgpTiOKMSdDkf.pgp Description: PGP signature
Re: File as a directory - VFS Changes
[EMAIL PROTECTED] wrote on Sat, 28 May 2005 15:42:35 -0400: > I'm not Hans, but I *will* ask "How much of this is *rationally* doable > without some help from the VFS?". At the very least, some of this stuff > will require the FS to tell the VFS to suspend its disbelief (for starters, > doing this without confusing the VFS's concepts of dentries/inodes/reference > counts is going to be interesting... :) Good point. One way would be to cram it into the existing VFS (the operating system's interface to file systems) as directories representing the objects, containing a specially named file for the raw data, mixed in with child items and symbolic links to parent objects. Some inodes would be fake ones, geneated as needed to represent the old style view of the file / directory / attribute thing (such as the parent symbolic links). But what would I (Hans likely has other views) like to see in a new VFS to support files / directories / attributes all being the same kind of object? I'll talk about the user level API view of the VFS, rather than the flip side for file systems or the gritty VFS internals, since it doesn't need to be Linux specific. For one, it would be almost the same as the existing VFS. But when you open a fildirute-thing, you can use the same file handle to read and write its data and to list its children. Thus open() and opendir() are combined into plain open(). It takes a conventional hierarchical path (or later some of Hans Reiser's more sophisticated namespaces?). Returns a file handle. The resulting file handle can be used with read(), write(), seek(), readdir(), rewinddir() and the rest of the usual directory and file basic operations. And of course, close() it when you're done. Stat() would disappear. All the miscellaneous stat data would be stored as sub-files, things like the date last modified, access permissions and so on. There would be a standard filename and file type for those metadata subfiles to distinguish them from user created subfiles (such as file/.meta.last_modified). That also makes it easier to add new kinds of metadata. And that's about it for the basics. Standard utilities, like "ls" would have to be changed to use the new object structure - listing the contents of a thing and avoiding recursion down paths that lead to parent objects (just like "ls" currently avoids listing ".." recursively). That may involve more work than the kernel changes! I'd add a multi-read function to replace stat(). Give it a list of sub-file names to read and it returns their names and contents in a packed list (like a dirent structure). That way bulk reading date stamps, permissions and other attributish small metadata as subfiles won't have as much overhead as opening then individually. Particularly if under the hood they are stored as fields in the file's inode rather than as totally separate files (this is what BeOS's BFS does for small attributes). Though conceptually you treat them as separate subfiles. I'd also like to add indexing. That could be done by creating a magic directory with an associated file type to index. Then whenever a file with that file type is changed, the index is updated using the file's contents as the key, and a link to the file as the value. The file type also implies the interpretation of the values for sorting purposes - as strings, binary numbers, etc. Unlike BeOS, I'd expose the indices directly (appearing as a directory full of hard links) and have query languages implemented in userland libraries that make use the indices, rather than as part of the file system. Now should indices be system wide and maintained by the VFS, or per-volume and maintained by the file system? How about indices for things on network drives? Things on public web sites for a web-view file system? I'd also like to add change notification. If a file system object's child list changes, then a notification message gets sent to interested listeners. Similarly for an object's data content change. BeOS had useful notifications for live changes to a query - I'd punt this to the userland query library and have it build on the change notifications from an index directory. The VFS and other parts of the OS would need to support change notification (BeOS used inter-process message queues). Can a file-as-directory system fit into Linux, or some other OS? I expect that it will only happen if the new system also exposes a backwards compatible view for old software, using the old APIs. After that's done, the first big user program that needs to be updated is the desktop file browser. Once there's a good GUI for browsing file-as-directory file systems, the general public might become more aware of their advantages (easily drilling down inside files to attach a description subfile or add a bunch of MP3 tags, magic query directories and indexing to find things quickly, multiple parents to put the same file in multiple folders without the breakability of sym
Re: Problems with accessing directory
On Tue, 29 May 2001 18:14:28 +0200, Webservice said: > When accessing a particulary directory, the systems hangs with a kernel > panic (mapping memory). This will be a lot easier to diagnose with: The exact version of your kernel (uname -a), the version of reiserfsck, and the actual panic traceback (set up a serial console to catch it, or even take a picture with a digital camera if all else fails). Have you run 'badblocks' on the 4 md devices, to rule out an actual bad spot on the disk? pgpFfAoRZDuOp.pgp Description: PGP signature
Problems with accessing directory
After a new build off a server we keep getting problems with it. The server is in software raid-1 (mirroring) with slackware 10.1 and reiserfs. When accessing a particulary directory, the systems hangs with a kernel panic (mapping memory). Memory has been changed twice without any effect. When starting up the machine we got lot (hundreds) of thes messages: md:reiserfsck (pid 106) used obsolete MD ioctl, upgrade your software to use new ictls. Then machine boots further, and it works normally until we access a perticulair directory. The server reboots or hangs with a kernel panic (mapping virtual memory) Switching to init 1 and then reiserfsck --rebuild-tree reports errors which can be fixed, but the problems still remains. /proc/mdstat gives no errors Personalities : [linear] [raid0] [raid1] [raid5] read_ahead 1024 sectors md0 : active raid1 sdb2[1] sda2[0] 19542976 blocks [2/2] [UU] md1 : active raid1 sdb3[1] sda3[0] 19542976 blocks [2/2] [UU] md2 : active raid1 sdb5[1] sda5[0] 19542976 blocks [2/2] [UU] md3 : active raid1 sdb6[1] sda6[0] 17293824 blocks [2/2] [UU] unused devices: any ideas? Thx in advandce...
Fwd: Bug#309512: reiserfsprogs: Typo in reiserfstune manpage
cheers domenico - Forwarded message from Dennis Brakhane <[EMAIL PROTECTED]> - Date: Tue, 17 May 2005 19:46:56 +0200 From: Dennis Brakhane <[EMAIL PROTECTED]> Subject: Bug#309512: reiserfsprogs: Typo in reiserfstune manpage Package: reiserfsprogs Version: 1:3.6.19-1 Severity: minor The manpage describes reiserfstune as a "tunning" tool. - End forwarded message - -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Exclusive notice
Time to start saving with generics! Try us nnoo
