On 2015-10-24 at 22:41 +0300, Georgios Tsalikis wrote: > On 24/10/2015 01:58 πμ, Ivan Shapovalov wrote: > > > 24 окт. 2015 г., в 1:06, Georgios Tsalikis <georgios.tsalikis@hol > > > .gr> написал(а): > > > > > > > On 24/10/2015 12:37 πμ, Ivan Shapovalov wrote: > > > > > On 2015-10-22 at 20:38 +0300, Georgios Tsalikis wrote: > > > > > The filesystem is 1.7GB large, lies in a GPT patition and is > > > > > formated > > > > > with -o node=node41 without any other override. The kernel is > > > > > 4.2.3 > > > > > with > > > > > the 4.2.2 patch. > > > > > I tried the same on a 250MB partition and it mounts > > > > > instantly. dmesg > > > > > shows nothing special > > > > > Any ideas? Thanks in advance. :) > > > > Hello, > > > > > > > > try "dont_load_bitmap" in mount options. However, this is > > > > anyway very > > > > strange for a ~2GB partition... > > > I am sorry, did i write 1.7GB? I meant 1.7TB... i am old and such > > > figures dont fit my mind easily! > > Ah, so it's 1.7 TB? Then it's not unusual at all. Indeed, try > > mounting with `-o dont_load_bitmap`. > > > I did so and it worked. Thank you. But what does that option do? This option tells reiser4 to load bitmap blocks on demand, and not all at once at filesystem mount time. The bitmap is how reiser4 stores information about which on-disk blocks are allocated and which are free (one bit corresponds to one block, hence the name). The 2TiB filesystem has 2*1024^4 / 4096 = 536870912 blocks, which take 536870912 / (8*4096) = 16384 bitmap blocks, so it takes 120/16384 ~ 7ms to load one block, which is not that unusual (given that the bitmap loading doesn't seem to be optimized too well: each block is read in a separate request). > And which are the other options and their function? I'm afraid that the full list of reiser4 options can only be found in code (file init_super.c, functions push_sb_field_opts() and reiser4_init_super_data(). -- Ivan Shapovalov / intelfx /
Attachment:
signature.asc
Description: This is a digitally signed message part
