I have asked this question on CS stack exchange. However, I want to ask it here also, maybe some Linux experts can help me out! I would be very grateful if someone can clarify a little bit about the Dancing tree data structure that the Reiser4 filesystem uses. It's a presentation topic that I picked, however, there seems to be little resource about it. The only things that I could found are: - Reiser4's description of Dancing Tree: http://web.archive.org/web/20071024001500/http://www.namesys.com/v4/v4.html#dancing_tree - The lookup operation of Dancing Tree: http://www.cofault.com/2006/03/reiser4-1-internal-tree.html I have understood the basic idea of Dancing Tree. As far as I know, it pretty much resembles B+ Tree. However, I can only guess how the insertion and deletion operations are carried out, as follows: - Insertion acts like insertion on B+ Tree (insert and possibly split) - Deletion operation deletes the entries but without combining if underflow (?) because we don't want to perform optimization every time we modify the tree. And my third question is: How does the dancing tree actually perform the "squeeze" operation before writing to disk? (as described in the Reiser4's description) I would really be thankful if someone can shed some light on this! I just hope to get some clarifications as this is pretty confusing to me right now.

I have a Debian 10 server with a 2TB drive where I want to store over 120 million small files. If I use ext4 I run out of inodes. What file system should I use? I've been reading about reiserfs and reiser4, but I'm not sure if either of them are still supported. Is there a file system with a built Debian package that I can use? The main use case is providing 256x256 raster map tiles to users with Apache. I'm guessing that speed isn't that important as the limiting factor will be the ping time. Using as much of the bytes as I can is mildly important, but I also have a lot of free disk space. Edit: The files are typically 1kb to 3kb.

I'm unable to mount my 300GB external (in external enclosure) HDD's single partition. None of the fsck tools add anything, they cannot even recognize the partition. I had forgotten whether I had used ext4 or reiserfs myself. The HDD seems ok. Testdisk saw a linux partition but didn't give any more details. Until ... I followed https://unix.stackexchange.com/questions/33284/recovering-ext4-superblocks and tried the sudo losetup -v -o $i /dev/loop1 /dev/sdc command. Now testdisk at least gives me a green label, tells me it's a reiserfs 3.6 partition and gets the correct device label! I especially had luck with i=32768: $ dmesg [10147.132161] REISERFS (device loop1): found reiserfs format "3.6" with standard journal [10147.132204] REISERFS (device loop1): using ordered data mode [10147.132206] reiserfs: using flush barriers [10147.132335] REISERFS (device loop1): journal params: device loop1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [10147.132745] REISERFS (device loop1): checking transaction log (loop1) [10147.133630] REISERFS warning: reiserfs-5090 is_tree_node: node level 61404 does not match to the expected one 4 [10147.133638] REISERFS error (device loop1): vs-5150 search_by_key: invalid format found in block 67403788. Fsck? [10147.133644] REISERFS (device loop1): Remounting filesystem read-only [10147.133652] REISERFS error (device loop1): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [1 2 0x0 SD] [10147.133660] REISERFS (device loop1): Using r5 hash to sort names I can't mount it as you see but to me it seems I'm getting close: $ sudo mount -t reiserfs /dev/loop1 /mnt mount: /dev/loop1: can't read superblock Am I seeing ghosts just because I skip some bytes? Why doesn't testdisk see this from the raw /dev/sdc1? I mostly used readonly tools but I might have asked testdisk to write once (to the partition table?) so I could have lost parts, though I don't doubt most can be recovered. **And most of all, how do I continue from here?** I could run reiserfsck on the raw /dev/sdc1, but if there's a reason why the offset works better, how do I consolidate it onto my HDD first? Please indicate the implications of your solution appropriately (how clean? if it writes I want to know). I am ok with giving up the data on the disk (nothing personal), but if it's easy to fix I'd like that. Also, Foremost seems to be able to recover my files, but I have no space to write them to. UPDATE1: Weird that I' m seeing less results on my actual laptop rather than on the Ubuntu LiveCD (perhaps this is the cause of my troubles). I tried some stuff and I only get some smartness from reiserfsck if I use the losetup from above and then run reiserfsck --check /dev/loop1. However it aborted replaying transactions it seems. I get: [ 682.743728] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 682.743734] ata1.00: ST-ATA: DRQ=0 without device error, dev_stat 0x50 [ 682.743740] ata1.00: failed command: DEVICE CONFIGURATION OVERLAY [ 682.743747] ata1.00: cmd b1/c2:00:00:00:00/00:00:00:00:00/40 tag 0 pio 512 in [ 682.743749] res 50/00:00:00:00:00/00:00:00:00:00/40 Emask 0x202 (HSM violation) [ 682.743753] ata1.00: status: { DRDY } [ 682.743763] ata1.00: hard resetting link [ 683.060965] ata1.01: hard resetting link [ 684.087234] ata1.01: failed to resume link (SControl 0) [ 684.243064] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 684.243086] ata1.01: SATA link down (SStatus 0 SControl 0) [ 684.283150] ata1.00: configured for UDMA/133 [ 684.283860] ata1: EH complete [ 727.846495] usb 2-1.3.1: reset high-speed USB device number 6 using ehci_hcd [ 766.757684] usb 2-1.3.1: reset high-speed USB device number 6 using ehci_hcd Is this a drive failure? Doesn't look like it. UPDATE2: It had to recreate the journal header, then had to recreate the superblock, and it is now rebuilding the tree (but at least it is doing something). From my experience that means I won't get to my data in a coherent fashion :-). But it is all doing this in the loop device. This brings me back to my initial question: **How will I ever get back from a working partition in a loop device to a directly accessible working partition (63 cylinders off I suppose)?** UPDATE3: I rebuilt the tree and got a lost+found with some stuff back. When trying to mount it the next day, it again could not be mounted. Overall it showed random behavior. I think the hard disk actually has died. SMART data was the first thing I tried but it could never be accessed, I - wrongly? - assumed this was because of the enclosure. I tried to format it with a new partition but even that wouldn't stick very long beyond the formatting.

I am using Plesk on an Ubuntu 14.04 server and experiencing some strange problems: I checked mount: /dev/vzfs on / type reiserfs (rw,usrquota,grpquota) Then stat /dev/vzfs: stat: cannot stat ‘/dev/vzfs’: No such file or directory Then df: Filesystem 1K-blocks Used Available Use% Mounted on /dev/vzfs 209715200 177877760 31837440 85% / none 2097152 4 2097148 1% /dev none 4 0 4 0% /sys/fs/cgroup none 419432 104 419328 1% /run none 5120 0 5120 0% /run/lock none 2097152 4 2097148 1% /run/shm none 102400 0 102400 0% /run/user And df -i: Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vzfs 18446744070447236696 18446744069415584328 1031652368 100% / none 524288 61 524227 1% /dev none 524288 1 524287 1% /sys/fs/cgroup none 524288 118 524170 1% /run none 524288 12 524276 1% /run/lock none 524288 2 524286 1% /run/shm none 524288 1 524287 1% /run/user The inode counts are terribly close to the 64 bit arithmetic limit, so I suspect an integer overflow to cause the problems. Other users cannot write to files thanks to quota limitations, even though I never set any specific quotas. I don't know how to debug and/or solve this problem, can someone help me with this? --- Update: I disabled quotas in the VPS settings of my provider, and mount now indicates that the type of the filesystem changed: /dev/vzfs on / type vzfs (rw,relatime) I also created the file in /dev using mknod, stat /dev/vzfs now says File: ‘/dev/vzfs’ Size: 0 Blocks: 0 IO Block: 4096 block special file Device: 9eh/158d Inode: 2347445354 Links: 1 Device type: 0,ba Access: (0644/brw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2017-07-11 16:59:42.471740071 +0200 Modify: 2017-07-11 16:59:42.471740071 +0200 Change: 2017-07-11 16:59:42.471740071 +0200 Birth: - df -i still shows this: Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vzfs 18446744070447246304 18446744069415584345 1031661959 100% / none 524288 62 524226 1% /dev none 524288 1 524287 1% /sys/fs/cgroup none 524288 120 524168 1% /run none 524288 12 524276 1% /run/lock none 524288 2 524286 1% /run/shm none 524288 1 524287 1% /run/user And there are still error messages: -bash: cannot create temp file for here-document: Disk quota exceeded --- I originally posted this question [at ask ubuntu](https://askubuntu.com/questions/935102/strange-inode-count-with-dev-vzfs) but it was suggested to post it here. --- Update: I restored a backup from a few days ago and the server seems to be running without problems. inode counts are back to normal, but I am pretty close to the inode limit set by my hosting provider, so that might be the problem.

I've got a server with 3 sata hard drives. Each has 2 partitions: one small is part of /dev/md0, a raid1 array (/boot), rest is part of a raid5 array (/dev/md1), which is an lvm physical volume. Inside it are 3 (IIRC) logical volumes. One of these is a reiserfs 3.6 fs holding about 100gigs of data. Yesterday this server crashed. At power up, SMART told me that one of the drives was dead. He was indeed making very bad noises. So I removed the failed drive, and tried to restart the system on the 2 remaining disks. Which failed. With a live cd, I started it and tried to restart the array. Unfortunately, mdadm refused to do so, because it thought one of the 2 remaining disks was failed also. So, following advice found at https://unix.stackexchange.com/questions/8861/how-to-recover-a-crashed-linux-md-raid5-array that looked like it could apply to my situation, I did something that was probably just plain stupid: I ran mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sd[ab]2 missing Now, I can actually start this array, but the lvm tools (vgscan, vgdisplay, pvck) cannot find anything related to lvm on the array, and I'm completely unable to get to my data. Did I just wipe all the lvm metadata? My feeling is that actual data is still there, undamaged (apart from lvm metadata). Is there a chance to get the data back? How? **UPDATE:** Following advice from psusi (below), I tried each of the following ways of re-creating the array: mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sda2 /dev/sdb2 missing mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sdb2 /dev/sda2 missing mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sda2 missing /dev/sdb2 mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sdb2 missing /dev/sda2 mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 missing /dev/sda2 /dev/sdb2 mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 missing /dev/sdb2 /dev/sda2 mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sda2 /dev/sdb2 missing mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sdb2 /dev/sda2 missing mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sda2 missing /dev/sdb2 mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sdb2 missing /dev/sda2 mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 missing /dev/sda2 /dev/sdb2 mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 missing /dev/sdb2 /dev/sda2 Which is basically all possible orders, both with -c64 and -c512. After each test, I ran a vgscan. None found anything. Maybe I should not use vgscan but some other tool? **UPDATE 2:** I gave a try at reconnecting the failed hard drive. And miracle, it seems to somewhat work. At least, enough to examine it: root@debian:~# mdadm --examine /dev/sda2 /dev/sda2: Magic : a92b4efc Version : 0.90.00 UUID : 1f5462ab:6945560d:019b01a5:914dd464 Creation Time : Fri Oct 17 12:40:40 2008 Raid Level : raid5 Used Dev Size : 160015360 (152.60 GiB 163.86 GB) Array Size : 320030720 (305.21 GiB 327.71 GB) Raid Devices : 3 Total Devices : 3 Preferred Minor : 1 Update Time : Tue Apr 12 08:15:03 2011 State : active Active Devices : 3 Working Devices : 3 Failed Devices : 0 Spare Devices : 0 Checksum : 64d514fb - correct Events : 137 Layout : left-symmetric Chunk Size : 64K Number Major Minor RaidDevice State this 0 8 2 0 active sync /dev/sda2 0 0 8 2 0 active sync /dev/sda2 1 1 8 18 1 active sync /dev/sdb2 2 2 8 34 2 active sync /dev/sdc2 So, is there a way to copy this superblock to the other 2 devices, so that I can start the array "properly"?

Ok, I have Ubuntu installed but I want to install Windows also (dual-boot). Problem is, I don't have a free partition. I have my root partition (15 GB), and my /home partition (300 GB). The home partition has about 50 GB free space, and it's formatted reiserfs. I've heard about tools like resize_reiserfs, and I even tried it yesterday - I shrunk my /home partition (it's on /dev/sda6) with the command: resize_reiserfs -s -20G /dev/sda6 After that gparted showed that the partition itself was 280 GB, but there was no way to create a new partition from the 20 GB. I ended up running resize_reiserfs -s +20G /dev/sda6 to restore my /home partition to its previous size.

I used the Reiser4 fs for some time and would love to see it get into the mainline kernel. I would think the project can still go forward even if Hans is not able to contribute these days. Is there any mention on a mailing list or elsewhere of plans to get Reiser4 into the mainline kernel?

On Jessie the only tools available are: /sbin/mkreiser4 /sbin/mkfs.reiser4 /sbin/fsck.reiser4 /sbin/debugfs.reiser4 /sbin/measurefs.reiser4 No one looks like useful to rename the label without reformatting the partition. Any clue? Thanks in advance.

Users vi and rust share group rust and want to use some file in shared manner. rust$ ls -l myfile -rw-rw-r-- 1 vi rust 0 May 30 03:48 myfile rust$ stat myfile | grep Gid Access: (0664/-rw-rw-r--) Uid: ( 1000/ vi) Gid: ( 1057/ rust) rust$ id uid=1048(rust) gid=1057(rust) groups=1057(rust),... rust$ cat myfile rust$ touch myfile touch: cannot touch ‘myfile’: Permission denied rust $ dd of=myfile dd: failed to open ‘myfile’: Permission denied vi$ id uid=1000(vi) gid=1000(vi) groups=1000(vi),{many unrelated groups skipped},1057(rust),{many unrelated groups skipped} vi$ touch myfile vi$ Only "vi" user has write access to the file despite of g+w. root# chown rust myfile rust$ ls -l myfile -rw-rw-r-- 1 rust rust 0 May 30 03:51 myfile vi$ touch myfile rust$ chmod g-w myfile vi$ touch myfile touch: cannot touch ‘myfile’: Permission denied vi can or can't write to rust's file depending on g+w bit, as excepted. Why group-writable bit works only in one direction? The file remains unavailable even in a+w mode. Third user can write to the file with a+w although... getfacl myfile returns Invalid argument. The file is on local reiserfs. id vi and id rust matches id in respective users' shells up to order of unrelated groups. --- One more experiment: vi$ chmod a+w myfile vi$ stat myfile File: ‘myfile’ Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fb02h/64258d Inode: 12618147 Links: 1 Access: (0666/-rw-rw-rw-) Uid: ( 1000/ vi) Gid: ( 1057/ rust) Access: 2016-05-30 18:49:20.000000000 +0300 Modify: 2016-05-30 20:48:23.000000000 +0300 Change: 2016-05-30 20:48:23.000000000 +0300 Birth: -

root# dived -J -u rust -g rust -- id
uid=1048(rust) gid=1057(rust) groups=1057(rust)
root# dived -J -u rust -g rust -- dd of=/home/vi/home/rust/myfile
dd: failed to open ‘/home/vi/home/rust/myfile’: Permission denied

root# dived -J -u rust -g 99999 -- id
uid=1048(rust) gid=99999 groups=99999
root# dived -J -u rust -g 99999 -- dd of=/home/vi/home/rust/myfile
sfdasafd
0+1 records in
0+1 records out
9 bytes (9 B) copied, 1.14971 s, 0.0 kB/s

A mystery. Can grsecurity patches be a problem? --- Next experiment: root# stat /home/vi/home/rust/myfile File: ‘/home/vi/home/rust/myfile’ Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fb02h/64258d Inode: 13848412 Links: 1 Access: (0664/-rw-rw-r--) Uid: (99997/ UNKNOWN) Gid: (99998/ UNKNOWN) Access: 2016-05-31 00:39:24.000000000 +0300 Modify: 2016-05-31 00:39:24.000000000 +0300 Change: 2016-05-31 00:39:24.000000000 +0300 Birth: - root# getfacl /home/vi/home/rust/myfile getfacl: /home/vi/home/rust/myfile: Invalid argument root# for i in {0..1099}; do if dived -J -u $i -g 99998 -- touch /home/vi/home/rust/myfile 2> /dev/null; then echo $i; fi; done 0 1000 root# root# root# mount -o remount,noacl /home root# root# for i in {0..1099}; do if dived -J -u $i -g 99998 -- touch /home/vi/home/rust/myfile 2> /dev/null; then echo $i; fi; done | head 0 1 2 3 4 5 6 7 8 9 (and so on, basically it works) root# mount -o remount,acl /home root# root# for i in {0..1099}; do if dived -J -u $i -g 99998 -- touch /home/vi/home/rust/myfile 2> /dev/null; then echo $i; fi; done | head 0 1000 root# Looks like getfacl (or it's kernel part) is a problem. ACLs are in effect, but are not manageable.

Hi my use case is quite specific. I have 20 Windows 7 machines constantly creating files in my storage; around 98% of these files are 2.1 MB. On average we create 24 million files every 3 days, and this number may increase in the near future as we may need to add new clients to our system. I do not modify files (just create, read, copy and delete). I have seen Reiser4, which looks promising, but I also would like to have the capability to replicate the files across multiple storage nodes across the network, so I can have a fault tolerance system in place. Any suggestion?

Is there an easy way to use Reiser4 on Debian Wheezy? I installed reiser4progs but obviously I need a patched Kernel as well to use it. Is there some semi-officially maintained kernel to install somewhere? Or which alternative filesystems (besides btrfs which I used before - it had severe CPU usage issues) for many small files can I use? **Edit:** I already found http://kernelnewbies.org/WhyReiser4IsNotIn (this is from 2006 so quite long ago, is it?) and http://sourceforge.net/projects/reiser4/files/reiser4-for-linux-3.x/ already, but I hoped there is a better way.

I have tried to format a partition on an USB pendrive with mkreiserfs 3.6.21 as follows: mkreiserfs --block-size=2048 /dev/sdb1 Which resulted in > Block sizes smaller than 4k are not supported. Interesting, because both info and man mkreiserfs describe as possible block size: > -b | --block-size N
N is block size in bytes. It may only be set to a power of 2 within the 512-8192 interval. So I tried it from the other end: > mkreiserfs /dev/sdb1 --block-size=8192 and got: Block sizes larger than 4k are not supported on all architectures. A bit picky, aren't we… Working with Linux 3.2.0-4-amd64 kernel I've tried the same as before in combination with the --format option. Same results. Question -------- *What am I doing wrong?* Some ideas I came across: - bad idea to create this on an USB device - *problem is located in the compiled version of mkreiserfs?* - (*bug in documentation*?) Yes, I know that reiser4 was created to replace reiserfs and it isn't very common anymore (or could I say "*is defunct*"?). ---------- Having little to no idea about .h files but at least willing to try to find anything informative, I found this in /usr/include/linux/reiserfs_fs.h - not helpful but worth sharing, I guess:

I have a VM server with an extra disk mounted on it. I have increased size on it from VMWare. The disk uses reiserfs file system.

 /dev/sdb1 /data/mysql_data reiserfs rw,relatime 0 0 

After expanding disk size, I run this

# fdisk -l
Disk /dev/sdb: 39.3 GB, 39322648576 bytes
255 heads, 63 sectors/track, 4780 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1        2611    20971488+  83  Linux

After this, I run

# resize_reiserfs -f /dev/sdb1
resize_reiserfs 3.6.21 (2009 www.namesys.com)

/dev/sdb1 already is of the needed size. Nothing to be done

and then df -h but still file system size hasn't increased.

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_0-lv_root
                       21G   12G  7.9G  60% /
tmpfs                1004M     0 1004M   0% /dev/shm
/dev/sda1             485M  156M  305M  34% /boot
/dev/sdb1              20G   15G  5.6G  73% /data/mysql_data

At the moment, my partition table says this

# cat ~/sfdisk_sdb.txt 
# partition table of /dev/sdb
unit: sectors

/dev/sdb1 : start=       63, size= 41942977, Id=83
/dev/sdb2 : start=        0, size=        0, Id= 0
/dev/sdb3 : start=        0, size=        0, Id= 0
/dev/sdb4 : start=        0, size=        0, Id= 0

So, what am I doing wrong?