Reiser4 acting wierd

[gerardo]

Sorry, another reiser4-thread.
I had a Reiser4 partition for root and two XFS partitions (one for /home)
I wanted to merge the two XFS partitions so I copied my home data to my root (Reiser4) to a separate folder (cp -a).
After using fdisk, I reformatted the drive to Ext4, but this was quite buggy. I lost disk access (also to my root) after formatting (either with patched version 1.39-r2 or 1.40.2).
So I chose to go for Reiser4 as well. How can I disable compress for Reiser4?
My data is mostly music and movies, which are hardly compressable...

A simple cp -a should put my data (20 Gigabytes) back, but each time I got a "Out of memory" for Reiser4.

Code:

Unable to handle kernel NULL pointer dereference at 0000000000000010 RIP:  [<ffffffff8031a8ec>] internal_at+0x1/0x18 PGD 3b374067 PUD 10fd9067 PMD 0 Oops: 0000 [2] PREEMPT SMP CPU 0 Modules linked in: w83627ehf i2c_isa eeprom rfcomm l2cap snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device fuse button fan cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative acpi_cpufreq freq_table processor nvidiafb fb_ddc i2c_algo_bit vgastate arc4 ecb blkcipher rc80211_simple rt61pci(F) rt2x00pci(F) rt2x00lib(F) firmware_class crc_itu_t mac80211 cfg80211 eeprom_93cx6 nvidia(PF) hci_usb bluetooth parport_pc parport snd_hda_intel snd_pcm snd_timer 8250_pnp snd snd_page_alloc r8169 i2c_i801 i2c_core pcspkr rtc floppy nfs lockd sunrpc jfs dm_mirror dm_mod scsi_wait_scan usbhid ff_memless ohci_hcd uhci_hcd usb_storage ehci_hcd usbcore Pid: 8966, comm: cp Tainted: PF      2.6.22-kamikaze5 #3 RIP: 0010:[<ffffffff8031a8ec>]  [<ffffffff8031a8ec>] internal_at+0x1/0x18 RSP: 0018:ffff81000e4f9658  EFLAGS: 00010292 RAX: ffffffff80610d48 RBX: ffff81000e4f96c8 RCX: 0000000000000000 RDX: ffff81003512e980 RSI: ffff81000e4f96c8 RDI: 0000000000000000 RBP: ffff81003512e980 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000000e R11: ffffffff80315eda R12: ffff810032346d38 R13: ffff81000e4f9908 R14: ffff81003512e990 R15: ffff81000e4f96c8 FS:  00002aeb08bca270(0000) GS:ffffffff80636000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000010 CR3: 0000000010b2a000 CR4: 00000000000006e0 Process cp (pid: 8966, threadinfo ffff81000e4f8000, task ffff81003ba6b080) Stack:  ffff81000e4f96c8 ffffffff8031a90c ffff810032346d38 ffffffff8031a91a  0000000000000000 ffffffff8030ec05 ffff81000e4f96c8 0000000000000000  0000000100000050 000000000000000f ffffffff8031026e ffff81000e4f9930 Call Trace:  [<ffffffff8031a90c>] pointer_at+0x9/0xe  [<ffffffff8031a91a>] has_pointer_to_internal+0x9/0x14  [<ffffffff8030ec05>] find_disk_cluster+0x1e9/0x32a  [<ffffffff8031026e>] flow_by_inode_cryptcompress+0x0/0x2f  [<ffffffff8030e968>] need_cipher+0x9/0x18  [<ffffffff8031be5e>] ctail_read_disk_cluster+0x69/0x165  [<ffffffff8031c008>] do_readpage_ctail+0xae/0x245  [<ffffffff8031c31d>] ctail_readpages_filler+0x17e/0x1c3  [<ffffffff8031c19f>] ctail_readpages_filler+0x0/0x1c3  [<ffffffff80262254>] read_cache_pages+0x86/0xe6  [<ffffffff80266dea>] __inc_zone_state+0x10/0x63  [<ffffffff80266dea>] __inc_zone_state+0x10/0x63  [<ffffffff8031c8cf>] readpages_ctail+0x2f0/0x32c  [<ffffffff80310457>] readpages_cryptcompress+0x3b/0x64  [<ffffffff80261e0e>] __do_page_cache_readahead+0x164/0x25f  [<ffffffff803ff53b>] radix_tree_scan_hole_backward+0x3a/0x8c  [<ffffffff80514c95>] _read_unlock_irq+0x12/0x2d  [<ffffffff802625e6>] try_context_based_readahead+0x332/0x371  [<ffffffff80261fce>] ra_submit+0xc5/0xcc  [<ffffffff80262926>] page_cache_readahead_adaptive+0x176/0x542  [<ffffffff80283f0d>] inode_get_bytes+0x37/0x3f  [<ffffffff8025c1a3>] do_generic_mapping_read+0x1ca/0x4f5  [<ffffffff8025b5e2>] file_read_actor+0x0/0x10b  [<ffffffff8025dd63>] generic_file_aio_read+0x121/0x15e  [<ffffffff80281205>] do_sync_read+0xd1/0x118  [<ffffffff8030bc08>] open_unix_file+0x2a/0x181  [<ffffffff8023e49e>] autoremove_wake_function+0x0/0x2e  [<ffffffff80289017>] may_open+0x5b/0x21b  [<ffffffff8028b5bc>] open_namei+0x2df/0x652  [<ffffffff80514b79>] _spin_unlock+0x14/0x31  [<ffffffff802f341a>] reiser4_grab+0x92/0x9c  [<ffffffff80311b67>] read_cryptcompress+0x6c/0x96  [<ffffffff8030db94>] prot_read_cryptcompress+0xe7/0x13f  [<ffffffff8028197b>] vfs_read+0xaa/0x132  [<ffffffff80281d0f>] sys_read+0x45/0x6e  [<ffffffff80209e9e>] system_call+0x7e/0x83 Code: 83 7f 10 ff 48 89 fb 75 05 e8 7f 70 00 00 48 89 df 5b e9 79 RIP  [<ffffffff8031a8ec>] internal_at+0x1/0x18  RSP <ffff81000e4f9658> CR2: 0000000000000010 reiser4[cp(8966)]: release_unix_file (fs/reiser4/plugin/file/file.c:2409)[vs-44]: WARNING: out of memory?

I split up my data in seperate folders and it copied with no problem but for one dir (still 17G).
Once I tried while compiling, which caused to crash the console I was working on. Killall cp didn't even help...
Both latest Kamikaze1 and Kamikaze5 sources had same effect.
So I tried cp -av rootfolder homefolder > /boot/copied and now it worked. I chose boot, because it's seperate from both Reiser4 partitions...
It doesn't seem I've lost some data, even after several hard resets...

Does anyone have had the same issues?
_________________
Windoze : Plug and Pay...

[Nsane457]

[ycUygB1]

My opinion is the Reiser4 is the buggiest fs, while XFS is the most reliable.
Swapping XFS for Reiser4 is therefore not a good idea if you value your data.
I think you just found that out.

I use XFS for everything now.

[darklegion]

XFS can't handle forced powerdowns or blackouts very well at all.Reiser4 may be buggy, but it's near foolproof against these cases.

[ycUygB1]

I am not aware of the XFS data loss problems.
What would the worst case scenario be?

With ext2, ext3, ext4, reiserfs, and reiser4 I have lost
all data on a drive at times. Especially when trying to add
lvm and raid1, you can lose a lot of data. As I said, this
has not happened with xfs. One gets the feeling of extreme
stability when running raid1/xfs drives. Of course, I have
UPS, so maybe I haven't run across the problems you mention.

[kernelOfTruth]

reverse waninkoko's reiser4 patch with

patch -p1 -R < reiser4-2.6.22.1.patch

then get yourself the latest reiser4-patch from namesys & try that:

ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.22/reiser4-for-2.6.22-2.patch.gz

that patch solved lots of issues for me - reiser4 still has 2 major probs I found - which shouldn't affect you in this case

if you've read the previous reiser4-thread you may have seen that it (still) can't be recommended for use with reiser4 for /root with "exotic" usage
-> if you regularly create backups go for it (using / testing) & help fix the remaining few flaws, then it will be ready for prime time (== mainline ?)

2 issues I know at the moment of are:
- it get screwed if used with 2.6.22-kernels and grsec => complete data loss
- creation of encrypted swap doesn't seem to work during startup (error in conjunction with /dev/urandrom / /dev/random)

so put reiserfs v3.6 on your /root and reiser4 on the other partitions you like

reiser4 until now has never lost any data on non-root partitions for me so it's rock stable for that usage

you still can move to reiser4 for /root in the near future after having created a stage4 tarball

instead of cp -a, you might want to try out rsync (e.g. rsync -aur /old /new) - that always worked for me, cp seems to do some stupid things - too

good luck

reiser4 without compression:
mkfs.reiser4 /dev/foo
(default file plugin or how it is called)
so just use this

reiser4 with compression :
mkfs.reiser4 -o create=ccreg40,compress=gzip1 /dev/foo
mkfs.reiser4 -o create=ccreg40,compress=lzo1 /dev/foo

reiser4 with tails plugin:
mkfs.reiser4 -o formatting=tails /dev/foo

reiser4 with extents plugin:
mkfs.reiser4 -o formatting=extents /dev/foo
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004

[John R. Graham]

Fascinating. Where did you learn about those options? Source code? I've hunted the web unsuccessfully for this documentation.

- John

[shaumux]