Re: Howto help hans?
Hi, On Sat, 02 Dec 2006 16:28:28 +0100, Clemens Eisserer wrote: Hello again, I just read in a german online news-site http://forum.tecchannel.de/news/themen/linux/456733/ that Hans' advocate Daniel Horowitz (I don't know wether this is the right word, that one how helps hans in front of the court) stopped working for hime because Hans was not able to pay him anymore. Hmm? I don't know how it is in the United States of America, but doesn't the plaintiff get an attourney paid by the court if he can't afford one? The page at http://forum.tecchannel.de/news/themen/linux/456733/ cites no source and since a report without a source attribution is not even worth the bits it is stored on, do we have some actual news report (as in, verifyable facts) somewhere? Is jdo an attribution? If they are verifyable, did someone from California check them yet? (I live waaay over the pond, so...) I don't know wether this is right or just imagination of newspapers, but if thats right we should help somehow. As far as I know there is currently no way of donating to Reiser4's developmant nore to help Hans in any way? Any ideas? Whats about registering a domain with sum fund stuff - donate to Reiser4 / help Hans? Does nobody care?! I do care and I set up a (small) pledge at pledgebank. Join it, please: http://www.pledgebank.com/hans-reiser What does an attourney cost for, say, 100 hours over there? Also, someone (best: multiple persons) from the Oakland, California area should attend the hearing at 11 Dec 2006 to see that nothing fishy goes on. cheers, Danny
Re: Which version will be merged into mainline kernel?
Hi, On Mon, 13 Nov 2006 17:34:59 +0800, Christopher Chan wrote: David Masover wrote: Christopher Chan wrote: [...smartdrv...] Yeah, smartdrv was nice :) [...] Try arguing why you lost thousands of mails when the box crashed and justifying it. Oh. Good point. So the bad case is: 1. mails are tiny 2. RAM cache is big 3. cache doesn't get flushed to disk for 1000s of mails 4. crash happens seldomly, but severely :) - 1000s of mail lost by the crash Now I see :) cheers, Danny
Re: Which version will be merged into mainline kernel?
Hi, On Sat, 11 Nov 2006 14:28:42 -0500, Valdis.Kletnieks wrote: [...] I've never understood this kind of attitude some filesystems have. Usually the hardware would make sure that stuff doesn't disappear, and not some weird software workarounds like journalling or write barriers that complicate and slow down everything. Now as you were saying? Hehehe. Well, you turned it all around... insightful :) While we are at it: I take it that this is the reason journalling support is only picking up now: the disks are so big that even in the unlikely event that some of the hardware failsafes fail, one just cannot fsck all the disks completely anymore, ever. So the choice is really 'borked once, borked forever' / 'journal it and at least somehow get it back online without fscking / copying-to-new-disks-if-at-all-possible for 5 days straight'. cheers, Danny
Re: Which version will be merged into mainline kernel?
Hi, On Wed, 08 Nov 2006 03:21:36 -0700, Andreas Dilger wrote: On Nov 08, 2006 10:15 +0100, Francesco Biscani wrote: I think the slow performance you're experiencing are caused by the fsync() call not being well-optimized in reiser4. I've commented out the function in fs/buffer.c, and I'm having much better performance on my / partition. I don't think this can be advocated as a real solution to performance problems. This can mean data loss for some applications like email that expect fsync return to mean this data is safely on disk. I've never understood this kind of attitude some MTAs have. Usually the hardware would make sure that stuff doesn't disappear (UPS, powered RAM, harddisk condenser) and not some weird software workaround that complicates and slows down everything. The only possibility one could still lose mail when having proper hardware failsafes would be if the kernel had a bug and crashed (and that's so bad, it doesn't really warrant any working around it). But maybe that's just me. cheers, Danny
Re: reiser4 cryptcompress test setup: bug
Hi, On Mon, 06 Nov 2006 17:07:16 -0500, Valdis.Kletnieks wrote: On Mon, 06 Nov 2006 19:27:57 GMT, Danny Milosavljevic said: Hi Edward, I finally tried your cryptcompress setup (2.6.18-mm3) and just did the first evil thing I could think of: the reiser4 partition with ccreg40 enabled is /dev/sda1 (/mnt/tmp/) (mkfs'ed, thus empty). [ 372.564358] [c01b6400] ext3_dirty_inode+0x30/0x90 [ 372.564364] [c016b4b9] cp_new_stat64+0xf9/0x110 You might want to check /home sometime - this looks like an ext3 botch rather than a reiserfs botch, unless reiser4 is stomping on something behind ext3's back. Well, I thought so at first, but: /home is reiser4 / is ext3 no other ext3s ~/doc/literatur is on /home (checked via 'df .'). So, well, although it looks like it ext3 is the culprit, it is improbable that it actually was the one triggering first (I never saw that backtrace before, too). Naturally once Edwards says he doesn't need the partition for analyzing, I'll nuke it and try to reproduce it again :) cheers, Danny
reiser4 cryptcompress test setup: bug
Hi Edward, I finally tried your cryptcompress setup (2.6.18-mm3) and just did the first evil thing I could think of: the reiser4 partition with ccreg40 enabled is /dev/sda1 (/mnt/tmp/) (mkfs'ed, thus empty). [EMAIL PROTECTED]: /mnt/tmp/dannym/ du -m ~/doc/literatur 2609/home/dannym/doc/literatur/ [EMAIL PROTECTED]: /mnt/tmp/dannym/ cp -R ~/doc/literatur . (hangs indefinitely) (note that 2609 MB is way too much to fit on the 250 MB memory stick, but that was the point, right :)) [EMAIL PROTECTED]: /mnt/tmp/dannym/ df /dev/sda1 /dev/sda1 242948242824 124 100% /mnt/tmp 'ps aux |grep cp' hangs. dmesg says: [ 84.597446] reiser4: sda1: found disk format 4.0.0. [ 88.544450] Bluetooth: Core ver 2.10 [ 88.544529] NET: Registered protocol family 31 [ 88.544531] Bluetooth: HCI device and connection manager initialized [ 88.544535] Bluetooth: HCI socket layer initialized [ 88.581518] Bluetooth: L2CAP ver 2.8 [ 88.581523] Bluetooth: L2CAP socket layer initialized [ 88.648403] Bluetooth: RFCOMM socket layer initialized [ 88.648422] Bluetooth: RFCOMM TTY layer initialized [ 88.648424] Bluetooth: RFCOMM ver 1.8 [ 372.564228] BUG: unable to handle kernel paging request at virtual address 4b1b5d0b [ 372.564235] printing eip: [ 372.564237] c01c498b [ 372.564238] *pde = [ 372.564242] Oops: [#1] [ 372.564243] PREEMPT [ 372.564246] last sysfs file: /block/sda/removable [ 372.564248] Modules linked in: rfcomm l2cap bluetooth binfmt_misc reiserfs hfs nls_utf8 hfsplus nls_cp437 ntfs vfat fat isofs udf capability commoncap cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand freq_table cpufreq_conservative video thermal sony_acpi backlight processor fan container button battery asus_acpi ac reiser4 zlib_deflate ext2 configfs dm_mod md_mod fusion fuse lp snd_seq_dummy snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq tuner i2c_viapro sg sd_mod ipv6 af_packet tsdev usbhid generic snd_via82xx snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401 snd_mpu401_uart usb_storage snd_rawmidi snd_seq_device bttv via_ircc video_buf ir_common snd ide_cd ehci_hcd irda analog compat_ioctl32 btcx_risc tveeprom parport_pc parport crc_ccitt aic7xxx rtc soundcore serio_raw cdrom floppy evdev psmouse pcspkr gameport videodev v4l1_compat v4l2_common via_agp agpgart scsi_transport_spi scsi_mod via_rhine uhci_hcd mii usbcore [ 372.564307] CPU:0 [ 372.564307] EIP:0060:[c01c498b]Not tainted VLI [ 372.564309] EFLAGS: 00010282 (2.6.18-mm3 #4) [ 372.564316] EIP is at journal_start+0x3b/0x100 [ 372.564319] eax: 4b1b5d0b ebx: f5fa0d20 ecx: f7dee400 edx: 0002 [ 372.564322] esi: f7c23960 edi: f5ab1990 ebp: 0002 esp: f514dec0 [ 372.564324] ds: 007b es: 007b ss: 0068 [ 372.564327] Process cp (pid: 4186, ti=f514c000 task=f57cc550 task.ti=f514c000) [ 372.564329] Stack: 0001 ffd8 c0170e86 f514df34 f514df34 f5fa0d20 f5ab1990 f5fa0d20 [ 372.564335]f5ab1990 0001 c01b6400 c016b4b9 f514df68 f5ab1990 f562b620 0003 [ 372.564340]c0186914 c011fb66 3b9aca00 f7dee400 f5ab1990 f562b620 0003 f7dee400 [ 372.564346] Call Trace: [ 372.564350] [c0170e86] may_open+0x66/0x260 [ 372.564358] [c01b6400] ext3_dirty_inode+0x30/0x90 [ 372.564364] [c016b4b9] cp_new_stat64+0xf9/0x110 [ 372.564371] [c0186914] __mark_inode_dirty+0x34/0x1c0 [ 372.564377] [c011fb66] current_fs_time+0x46/0x50 [ 372.564386] [c017d4ad] touch_atime+0x5d/0xb0 [ 372.564394] [c014681b] generic_file_mmap+0x3b/0x40 [ 372.564399] [c01594b9] do_mmap_pgoff+0x429/0x770 [ 372.564414] [c01077ce] sys_mmap2+0xbe/0xe0 [ 372.564424] [c0103065] sysenter_past_esp+0x56/0x79 [ 372.564435] === [ 372.564436] Code: 85 f6 89 5c 24 18 bb e2 ff ff ff 89 6c 24 24 89 d5 89 7c 24 20 8b 00 8b 80 bc 04 00 00 89 44 24 14 74 3e 85 c0 74 50 89 c3 8b 00 3b 30 74 2e c7 44 24 10 3c 9b 34 c0 c7 44 24 0c 0f 01 00 00 c7 [ 372.564456] EIP: [c01c498b] journal_start+0x3b/0x100 SS:ESP 0068:f514dec0 [ 372.564461] I'll leave the /dev/sda1 untouched in case we need it (well, I'll unmount it since I can't sleep with the fan noise :)) Tell me if you need anything... cheers, Danny
Re: a bit OT: traditional Unix filesystems
Hi, On Thu, 14 Sep 2006 13:05:44 -0400, Payal Rathod wrote: Hi, I have a small OT query on working of traditional filesystem of Unix. Can someone comment/correct me on the query below? If i type $ cat /tmp/payal.txt (according to my knowledge) [...] [unverified by me, and unrelated] Now if tmp is on different partition or harddisk, how will directory entry of ? point it out exactly? The kernel has a list of mountpoints (see /proc/pid/mounts) per process. It looks there if path argument starts with one of those, and if so, passes the path on to the topmost filesystem handler for that mountpoint (it also knows the device, it is part of the mountpoint list). As far as I know, directory entry contains names and inode number and not the device details, then how does it exactly work? For mountpoints, the kernel checks the mountpoint table (in kernel memory, per process) before passing the request on to the (topmost) filesystem that handles that prefix (which reads the directory entry and fetches the inode mentioned there). cheers, Danny
Re: cryptcompress 2.6.16-5 reiser4 and/or 2.6.17-mm5
Hi, On Sat, 12 Aug 2006 17:14:34 +0400, Edward Shishkin wrote: Danny Milosavljevic wrote: [...] Hmm... This is for internal usage only. I have removed it, sorry (nothing really confidential, but this stuff changes disk format including your old reiser4 partitions). Wait for official release. Everyone who wants to test it, send us a private message. I am trying it on another computer that doesn't have anything on it, so no danger here. [...] Should I do it differently? Is it ok to start from reiser4-for-2.6.16-2.patch as README says? Yes, follow the instructions precisely, and please, read warnings in the README carefully. libaal-1.0.5 - ok. Okay :) cheers, Danny
cryptcompress 2.6.16-5 reiser4 and/or 2.6.17-mm5
Hi, So after an insane amount of time of slacking off I'm actually trying the cryptcompress stuff now... However, I face some problems setting it up, because I deviate from the instructions :) What I tried: 1) download ftp://ftp.namesys.com/pub/tmp/cryptcompress_patches/2.6.16/ reiser4progs-1.0.6.tar.gz 2) compile and run, ./mkfs.reiser4 -o create=ccreg40 /dev/sda1 in the source directory Works fine, it seems (note that I used libaal 1.0.5). 3) get my 2.6.17-mm5 version without any extra patches to support it (probably no use trying, but...) mount /dev/sda1 /mnt/tmp dmesg [ 3584.914789] reiser4[mount(28515)]: plugin_by_unsafe_id (/home/dannym/work/src/kernels/linux-2.6.17/fs/reiser4/plugin/plugin.c:276) [nikita-2913]: [ 3584.914792] WARNING: Invalid plugin id: [16:4] [ 3584.914798] reiser4[mount(28515)]: unknown_plugin (/home/dannym/work/src/kernels/linux-2.6.17/fs/reiser4/plugin/item/ static_stat.c:58)[nikita-620]: [ 3584.914801] WARNING: Unknown plugin 4 in 42 [ 3584.914804] reiser4[mount(28515)]: init_inode_static_sd (/home/dannym/work/src/kernels/linux-2.6.17/fs/reiser4/plugin/item/ static_stat.c:177)[nikita-631]: [ 3584.914807] WARNING: unused space in inode 42 failed (as expected, probably)... 4) okay, so I thought it was time to do it properly and tried to use 2.6.16 vanilla, plus ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/ reiser4-for-2.6.16-5.patch.gz plus ftp://ftp.namesys.com/pub/tmp/cryptcompress_patches/2.6.16/patches/* Unfortunately, the patches from the last URL do not apply to that (most were already applied, save a few hunks that actually did get applied fine and the small remainder of rejects). trying to mount the filesystem with that kind of monster kernel (yeah, I actually finished compiling that kernel :)) causes: mount /dev/sda1 /mnt/tmp reiser4[mount(1190)]: init_read_super (fs/reiser4/init_super.c:602)[nikita-2608]: WARNING: mmcblk0p1: wrong master super block magic So, are there any more current 2.6.16 cryptcompress patches? Should I do it differently? Is it ok to start from reiser4-for-2.6.16-2.patch as README says? I figured rather start from the latest reiser4 fixes so that my testing makes any sense... (as for my choice of 2.6.16, it's the one with the newest mtime on the directory (ftp://ftp.namesys.com/pub/reiser4-for-2.6/;), and it was easier to do :)) cheers, Danny
Re: script binding for reiserfs?
Hi, Am Samstag, den 08.04.2006, 12:16 +0800 schrieb Dongxu Ma: On 4/8/06, Peter van Hardenberg [EMAIL PROTECTED] wrote: Dongxu, Reaching into the filesystem itself for a project like this is not a very good idea. A wiki is a set of files -- let the filesystem do the hard work for you and use the standard API that is already in existence -- the VFS. You'll get all the benefits of the Reiser filesystem without having to break compatibility with other systems. my own thought is that one can operate the filesystem, or at least query it via programming interface, you know, well, use the usual interface: stat creat lockf open write read close truncate unlink opendir readdir closedir rename sendfile utime readlink I don't get what good it would do to use some extra interface with different functions, given that all possible basic actions are already covered... (although transactions would be nice to have ;)) introduce shell is really a bad idea. What do you mean by that? I think a DBI/DBD interface to a Reiser-friendly file format is a really neat idea. You could create table rows as individual files within a directory and do foreign keys with links! You mean like in a relational database? That's very unflexible and a bad idea on a filesystem. There is a reason relational databases are only used properly in well-defined and limited-size big-design-up-front projects. And good relational databases are not even stored in files, but directly onto the raw partition. I wonder what on-disk form would leverage Reiser4's dancing trees and intelligent allocation the most efficiently? Yeah, I can store each field into a file, and creat view and table structure from directory and links. With the help of reiserfs, I assume this could be possible to try. It really depends on what you want to do with it, but of course you can store each field into a file of it's own. The question is if you need that kind of fine granularity... cheers, Danny I must say though, there is no binding to the Reiser4 API, and the Namesys team is very busy right now working towards getting R4 included in the mainline kernel. Hopefully once they have achieved this, the more exciting development can continue. 2.6.16 is a big step;-P As for your second question, my experience is strictly with R4, so someone else will have to comment on that issue. Anyway, great help for me, thanks. All the best, Peter van Hardenberg On 4/6/06, Dongxu Ma [EMAIL PROTECTED] wrote: Hi all, As reiserfs more and more popular, is there any binding package for use in script languages? I did a search on Google and nothing found. Curently I am thinking about writing a binding for Perl, which can offer: 1) script-level operation against reiserfs 2) DBI DBD for reiserfs binding to treat the fs as a database. My aim is constructing a mid-and-small wiki directly on reiserfs without employing any real database However, after some seeking on source. I got several issues: 1) is there any so-called official userspace api exported? On gentoo there is a package named progsreiserfs introducing an api set under /usr/include/reiserfs, but I am not very sure if it is stable and the project is still alive. 2) regarding reiser3, where could I start to port? since exporting something in kernelspace is quite risky. Any advice and hint? -- Cheers, Dongxu __END__ dongxu.wordpress.com search.cpan.org/~dongxu -- Peter van Hardenberg Victoria, BC, Canada The wise man proportions his belief to the evidence. -- David Hume -- Cheers, Dongxu __END__ dongxu.wordpress.com search.cpan.org/~dongxu
Re: 2.6.16 patch
Hi, Am Dienstag, den 28.03.2006, 14:54 +0200 schrieb Tassilo Horn: Vladimir V. Saveliev [EMAIL PROTECTED] writes: Hi Vladimir, sorry for delay: No problem. ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/reiser4-for-2.6.16-1.patch.gz The machine seems to be not available... works here cheers, Danny
Re: random minor benchmark: Re: Copy 20 tarfiles: ext2 vs (reiser4, unixfile) vs (reiser4,cryptcompress)
Hi, Am Donnerstag, den 26.01.2006, 21:41 +0300 schrieb Edward Shishkin: Danny Milosavljevic wrote: Hi, Nice :) Just curious, is there a description how to enable cryptcompress for files somewhere? (or is it still bleeding-edge ? :)) cheers, Danny Hello. If you have a free partition and a time to report about possible bugs, we'll send you a setup against 2.6.15-mm4 with the description. yes, now I do :) Thanks, Edward. cheers, Danny
Re: random minor benchmark: Re: Copy 20 tarfiles: ext2 vs (reiser4, unixfile) vs (reiser4,cryptcompress)
Hi, Nice :) Just curious, is there a description how to enable cryptcompress for files somewhere? (or is it still bleeding-edge ? :)) cheers, Danny
