Re: Authoring a versioning plugin
Hans Reiser wrote: >: > > > > I am skeptical that having it occur with every >write is desirable actually. > > Consider the case where you type cat file1 >> file2. This will produce a version of file2 for every 4k that is in file1, because (well I didn't look at the bash source, but I would guess) it appends in 4k incremental writes rather than one big write. Versioning on file close makes more sense, but I suggest manual control using the /checkin pseudofile, and then we can reasonably make it the default plugin for the whole FS (write it so that it calls the other plugins so that when we change the other plugins we don't need to change your code to do it). People who don't want versioning will simply never touch the checkin pseudofile. Make sure that for that case there is just an if statement condition check as overhead, and there will be no reason to not make versioning the default plugin that happens to do nothing unless you use the checkin pseudofile at least once during the life of the file. hmm, maybe /snap is better than /checkin ? Well, let's decide that once the code is written;-) Do you agree with my points here? Hans
Re: Authoring a versioning plugin
Yoanis Gil Delgado wrote: >This are the intentions: >To write a versioning plugin that will allows the file system user to easily >revert the files under versioning to a some previous state. The plugin will >allow to revert the file state, based on revisions number and date >modifications(and not sure about this one). There will be a special pseudo >file named "previous" that will return the previous version of the file. The >final result should allow to the the following actions: > >$ echo 1 > myfile.txt (let's say we make this command at Wed Jan 11 16:53:55) >$ echo 2 > myfile.txt (let's say we make this command at Wed Jan 11 16:54:57) >$ echo 3 >> myfile.txt (let's say we make this command at Wed Jan 11 16:55:59) > >Suppose you want the latest version, then you type: >$ cat myfile/.../previous > > "" not "..." ;-) > Some other content >Or you want the n-th version, then you type: >$ cat myfile/.../1 > Some content >$ cat myfile/.../2 > Some other content >$ cat myfile/.../3 > Some other content > Some more content >$ >Or the version nearest to some date, then you type: >$ cat myfile.txt/.../Wed\ Jan\ 11\ 16:50 > Some other content > >Also , there will be an special attribute named under_versioning(or something >like that), that will tell if the file is under versioning. This plugin will >not track directories version, although it's a future plan(I think this >should be mixed with some undelete plugin). > > How about using myfile//1 ;-) >I'm planning to use a delta techniques for versioning storage (delta >compression). > Ok, good. > The versioning will be at the write level. > Please make two plugins, one of which is the default, and for which versioning occurs only when you touch myfile//checkin, and the other occurs with each change. I am skeptical that having it occur with every write is desirable actually. > The versions will be >saved in a special directory under the filesystem. I think the hard part is >the one related to detecting the changes (a COW it's a possible solution, but >i think it's to expensive). I'm thinking a possible solution will be >detecting the bytes changing in each write and archiving then as the >difference. This introduce some problems like : >1-) What happens if the file shrinks? >2-) What happens if the file grows ? > > Please consider that myfile//checkin will be less work to code. >I will send another email with a solution to this problems. > >I've also plans to extent the documentantion of plugins creation in reiser4 >with the experiences of this project. I'll be working in this plugin for more >than 4 months. If you're interested you're welcome to the the team(just me >right now :D ) > > >Well... I think this is all (for now :D ). Please let me know what you >think. > > This all seems great! > > > > > > >
Authoring a versioning plugin
This are the intentions: To write a versioning plugin that will allows the file system user to easily revert the files under versioning to a some previous state. The plugin will allow to revert the file state, based on revisions number and date modifications(and not sure about this one). There will be a special pseudo file named "previous" that will return the previous version of the file. The final result should allow to the the following actions: $ echo 1 > myfile.txt (let's say we make this command at Wed Jan 11 16:53:55) $ echo 2 > myfile.txt (let's say we make this command at Wed Jan 11 16:54:57) $ echo 3 >> myfile.txt (let's say we make this command at Wed Jan 11 16:55:59) Suppose you want the latest version, then you type: $ cat myfile/.../previous Some other content Or you want the n-th version, then you type: $ cat myfile/.../1 Some content $ cat myfile/.../2 Some other content $ cat myfile/.../3 Some other content Some more content $ Or the version nearest to some date, then you type: $ cat myfile.txt/.../Wed\ Jan\ 11\ 16:50 Some other content Also , there will be an special attribute named under_versioning(or something like that), that will tell if the file is under versioning. This plugin will not track directories version, although it's a future plan(I think this should be mixed with some undelete plugin). I'm planning to use a delta techniques for versioning storage (delta compression). The versioning will be at the write level. The versions will be saved in a special directory under the filesystem. I think the hard part is the one related to detecting the changes (a COW it's a possible solution, but i think it's to expensive). I'm thinking a possible solution will be detecting the bytes changing in each write and archiving then as the difference. This introduce some problems like : 1-) What happens if the file shrinks? 2-) What happens if the file grows ? I will send another email with a solution to this problems. I've also plans to extent the documentantion of plugins creation in reiser4 with the experiences of this project. I'll be working in this plugin for more than 4 months. If you're interested you're welcome to the the team(just me right now :D ) Well... I think this is all (for now :D ). Please let me know what you think.
Really high load/mmap() issue on 2.6.14
Hi, Although I've surfed the archives from November to January and I found some mails complaining about the annoying mmap() issue on 2.6.14 (between viagra and OEM soft mails -arrrg), I decided to ask by myself what is the actual state of this bugs. Everytime I use my reiser4 laptop I suffer a lot of high load, making my machine _completely_ unusable for minutes. There is no apparent reason for that but if someone knows how to report any kind of useful information I will provide it. So, what's the actual state of the mmap() bug and that strange high load problem? Is 2.6.15 patch comming soon on our theatres? Kind regards :) -- GnuPG key ID 0x6D2FF8B5 @ pgp.escomposlinux.org Gentoo Linux on x86|sparc http://fluzo.org/
Forced sync bug
Hi guys, I'm not quite sure of what's happening, but I'll try to be as simple and clear as possible. My system has a reiser4 root filesystem that was working fine until a decided to do a complete update (with yum). I started to get oops related to the filesystem (a /var/log/messages is attached) for operations that were previously working fine. I guess that is something related with the forced (synchronous) sync operations, because (i) I get the oops in the following conditions: 1. Boot the system in any runlevel, mount a filesystem (cd, usb pendrive, vfat partition, even a reiser4 fs on a loopback device) and immediately umount it; 2. Boot in single user mode, and immediately shutdown the system (will get the oops for the swap unmount operation); (ii) If I wait enough for the low-overhead asynchronous sync, that system appears to work fine: 1. Boot the system in any runlevel and do (at the same time) - it should be more than enough to stress the filesystem a. recompile the whole kernel directory; b. do a rpm -V at every single package of the system (with a bash for loop) c. prelink every library and binary of the system 2. After everything is finished, wait a little bit (about a minute) close every xterm, shutdown X, logout, wait a little bit (about a minute) and shutdown the system - it works fine (no oops at all)! Note: At first I didn't update the kernel. They started to happen with the same 2.6.14 kernel. Just did the packages update. Then I tried to update the kernel (2.6.15-rc5-mm3) but the problems remain the same. Note 2: From my point of view, the only significant thing it was updated was the glibc. Previously it was version 2.3.5-10 and now: 2.3.5-10.3 Specifications Distribution: Fedora Core 4 (Stentz) Kernel version: 2.6.15-rc5-mm3 glibc version: 2.3.5-10.3 liball version: 1.0.5 reiser4progs version: 1.0.5 Dec 21 14:15:25 asgard syslogd 1.4.1: restart. Dec 21 14:15:26 asgard kernel: klogd 1.4.1, log source = /proc/kmsg started. Dec 21 14:15:26 asgard kernel: Linux version 2.6.15-rc5-mm3 ([EMAIL PROTECTED]) (gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 Wed Dec 21 12:13:26 BRST 2005 Dec 21 14:15:26 asgard kernel: BIOS-provided physical RAM map: Dec 21 14:15:26 asgard kernel: BIOS-e820: - 0009f800 (usable) Dec 21 14:15:26 asgard kernel: BIOS-e820: 0009f800 - 000a (reserved) Dec 21 14:15:26 asgard kernel: BIOS-e820: 000ec000 - 0010 (reserved) Dec 21 14:15:26 asgard kernel: BIOS-e820: 0010 - 0bbf (usable) Dec 21 14:15:26 asgard kernel: BIOS-e820: 0bbf - 0bbffc00 (ACPI data) Dec 21 14:15:26 asgard kernel: BIOS-e820: 0bbffc00 - 0bc0 (ACPI NVS) Dec 21 14:15:26 asgard kernel: BIOS-e820: fffe - 0001 (reserved) Dec 21 14:15:26 asgard kernel: 187MB LOWMEM available. Dec 21 14:15:27 asgard kernel: DMI 2.2 present. Dec 21 14:15:27 asgard kernel: Allocating PCI resources starting at 1000 (gap: 0bc0:f43e) Dec 21 14:15:27 asgard kernel: Built 1 zonelists Dec 21 14:15:27 asgard kernel: Initializing CPU#0 Dec 21 14:15:28 asgard kernel: Kernel command line: 3 ro root=/dev/hda2 ide0=ata66 ide1=ata66 pci=usepirqmask quiet Dec 21 14:15:28 asgard kernel: ide_setup: ide0=ata66 -- OBSOLETE OPTION, WILL BE REMOVED SOON! Dec 21 14:15:28 asgard kernel: ide_setup: ide1=ata66 -- OBSOLETE OPTION, WILL BE REMOVED SOON! Dec 21 14:15:28 asgard kernel: PID hash table entries: 1024 (order: 10, 16384 bytes) Dec 21 14:15:28 asgard kernel: Detected 448.430 MHz processor. Dec 21 14:15:28 asgard kernel: Using tsc for high-res timesource Dec 21 14:15:28 asgard kernel: Console: colour VGA+ 80x25 Dec 21 14:15:28 asgard kernel: Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Dec 21 14:15:28 asgard kernel: Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Dec 21 14:15:28 asgard kernel: Memory: 186180k/192448k available (2104k kernel code, 5740k reserved, 614k data, 136k init, 0k highmem) Dec 21 14:15:28 asgard kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok. Dec 21 14:15:29 asgard kernel: Calibrating delay using timer specific routine.. 901.32 BogoMIPS (lpj=1802655) Dec 21 14:15:29 asgard kernel: Security Framework v1.0.0 initialized Dec 21 14:15:29 asgard kernel: SELinux: Disabled at boot. Dec 21 14:15:29 asgard kernel: Capability LSM initialized Dec 21 14:15:29 asgard kernel: Mount-cache hash table entries: 512 Dec 21 14:15:30 asgard kernel: CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) Dec 21 14:15:30 asgard kernel: mtrr: v2.0 (20020519) Dec 21 14:15:31 asgard kernel: CPU: AMD-K6(tm) 3D processor stepping 0c Dec 21 14:15:31 asgard kernel: Checking 'hlt' instruction... OK. Dec 21 1
Re: Reiser disc hosed?
On Saturday 07 January 2006 06:46, Eric P wrote: > So I'm doing an 'mplayer -dumpfile', and before I know it I've > completely filled the last 10GB of my hard drive (total 80GB). It > wasn't were the OS resided; just a HD used for a file holding space. > > Anyway, after reaching 100%, the folder I was working in became > non-working. When I would do 'ls' from its parent folder, it said > something like 'Couldn't lstat /folder permission denied'; even as root. > > (sorry if my details are sketchy. Unfortunately, I tried tackling > this problem while I had a fever. Bad idea.). > > > It's a reiser4 FS, so I umounted and ran: > # fsck.reiser4 /dev/hdb1 > ... > Warn : Fatal corruptions were found. Semantic pass is skipped. > * fsck.reiser4 finished at Thu Jan 5 18:35:18 2006 > Closing fs...done > > 1 fatal corruptions were detected in FileSystem. Run with --build-fs > option to fix them. have you run fsck.reiser4 --build-sb before running this to rebuild the super block? > So, as suggested, I ran: > # fsck.reiser4 --build-fs /dev/hdb1 (which ran for ~30 min) > ... > Warn : Reiser4 storage tree does not exist. Filter pass skipped. > ... > Fatal: No reiser4 metadata were found. Semantic pass is skipped. > * fsck.reiser4 finished at Thu Jan 5 19:16:50 2006 > Closing fs...done > > NO REISER4 METADATA WERE FOUND. FS RECOVERY IS NOT POSSIBLE. it looks like it is not reiser4 or probably the partition table got corrupted or the fs was wiped out somehow. If you need our assistance, visit www.namesys.com/support.html please. > So this is (ahem) bad, huh? Am I screwed? Or is there any way to > recover some of the files? > > Thanks for reading! > Eric P. > > -- Vitaly
vs-4080
Hello, This morning I found the following warning on my Debian server holding a 253 GB Debian archive mirror: ReiserFS: dm-8: warning: vs-4080: reiserfs_free_block: free_block (dm-8:46707368)[dev:blocknr]: bit already cleared If fixed it with --fix-fixable, but what was it and what does it mean? Thanks, Ray
Troubles after --rebuild-tree
Hello everyone, I'm new on this list so first I would like to say hi :) I have a problem: We have a reiserfs partion in use on one of the servers. Because some files that were deleted had to be recoverd, the command reiserfsck --rebuild-tree -S -l /root/recovery.log was run. No backup of the partion was made before running this command. Yes, we know, don't even start.. The first time, in the first 1 or 2 minutes it was interrupted. After that, it was rerun and finished. We remounted the filesystem and that is where troubles began. Some files seem to be missing. Others appear damaged. We do have the logfile and the lost+found directory full or files. Is there any chance to repair the damage done with these two, or at least get some data back? How can this be done? Or should we leave it up to the expert? Any help or suggestions would be appreciated. Regards, Sander
Re: reiser4 warning?
E.Gryaznova wrote: > Hello. > > > Louis-David Mitterrand wrote: > >> Hello, >> >> When rebooting a server I catched this in the logs: >> >> Jan 10 18:13:55 zenon kernel: <4>reiser4[apache-perl(6359)]: >> disable_write_barrier (fs/reiser4/wander.c:233)[zam-1055]: >> Jan 10 18:13:55 zenon kernel: WARNING: disabling write barrier >> >> Is it bad? >> >> > No. You may ignore this warning. > > Thanks, > Lena. > >> (using 2.6.14 patch) >> >> >> >> > > > Always explain things like this to users, don't just tell them to ignore it, tell them why they can ignore it. Zam, please send in the patch to change it to a notice instead of warning. Hans
Re: reiser4 warning?
Hello. Louis-David Mitterrand wrote: Hello, When rebooting a server I catched this in the logs: Jan 10 18:13:55 zenon kernel: <4>reiser4[apache-perl(6359)]: disable_write_barrier (fs/reiser4/wander.c:233)[zam-1055]: Jan 10 18:13:55 zenon kernel: WARNING: disabling write barrier Is it bad? No. You may ignore this warning. Thanks, Lena. (using 2.6.14 patch)
