Reiser4 extremely slow at deleting.

Reiser4 extremely slow at deleting.

[Georgios Tsalikis]

It is almost always like this. For example a directory with 2.5GB of 
large files takes about 2 minutes. Right now i am deleting a large 
directory with small files, I didn't keep the numbers before running, 
but they are many directories with source code. Could it be 
fragmentation? And how could I mitigate it? Thanks

Re: Reiser4 extremely slow at deleting.

[Morgan Smith]

Was the file system created using the reg40 plugin or ccreg40 for on the
fly compression?

It seems to me I had this issue when using ccreg40 for on the fly
compression. I wrote a similar request for help some years ago and I
believe the answer was to not use compression. IIRC it's not an issue
with the compression itself rather the handling of allocated space for
it and the shuffling that is done when releasing resources. I was unable
to quickly find my old email to the list to confirm :(

On 07/27/2016 11:51 AM, Georgios Tsalikis wrote:
> It is almost always like this. For example a directory with 2.5GB of
> large files takes about 2 minutes. Right now i am deleting a large
> directory with small files, I didn't keep the numbers before running,
> but they are many directories with source code. Could it be
> fragmentation? And how could I mitigate it? Thanks
> 
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe
> reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reiser4 extremely slow at deleting.

[Georgios Tsalikis]

Here is my disappointing data :p

# measurefs.reiser4 -p /dev/sdc3
measurefs.reiser4 1.1.0
Format release: 4.0.1
Copyright (C) 2001-2005 by Hans Reiser, licensing governed by 
reiser4progs/COPYING.

Default profile:
create:          "ccreg40"         (id:0x4 type:0x0)    [Regular file 
plugin for creat(2)]
key:             "key_large"       (id:0x1 type:0xb)    [Key plugin]
node:            "node40"          (id:0x0 type:0x2)    [Node plugin]
compress:        "lzo1"            (id:0x0 type:0xc) [Compression plugin]
compressMode:    "conv"            (id:0x4 type:0xd) [Compression Mode 
plugin]
cluster:         "64K"             (id:0x0 type:0x10)    [Cluster plugin]
hash:            "r5_hash"         (id:0x1 type:0x3)    [Directory entry 
hash plugin]
fibration:       "ext_1_fibre"     (id:0x2 type:0x4)    [Key fibration 
plugin]
formatting:      "smart"           (id:0x2 type:0x5)    [File body 
formatting plugin]

(actually i formatted it with node41 but it doesn't appear so)

# ls -l resstick.dd
-rw-r--r-- 1 root root 22007840768 Ιούλ 26 15:03 resstick.dd
# time rm resstick.dd

real    21m43.005s
user    0m0.000s
sys    5m2.132s

If this is not problematic then what is? It is a single deletion!!


On 27/07/2016 09:15 μμ, Morgan Smith wrote:
> Was the file system created using the reg40 plugin or ccreg40 for on the
> fly compression?
>
> It seems to me I had this issue when using ccreg40 for on the fly
> compression. I wrote a similar request for help some years ago and I
> believe the answer was to not use compression. IIRC it's not an issue
> with the compression itself rather the handling of allocated space for
> it and the shuffling that is done when releasing resources. I was unable
> to quickly find my old email to the list to confirm :(
>
> On 07/27/2016 11:51 AM, Georgios Tsalikis wrote:
>> It is almost always like this. For example a directory with 2.5GB of
>> large files takes about 2 minutes. Right now i am deleting a large
>> directory with small files, I didn't keep the numbers before running,
>> but they are many directories with source code. Could it be
>> fragmentation? And how could I mitigate it? Thanks
>>
>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe
>> reiserfs-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reiser4 extremely slow at deleting.

[Edward Shishkin]

By default compression is turned on, and the file system tries to be 
"smart".
However, default heuristics is not perfect. It works well for "/" 
(setups created
during system installation). Also it works fine for various development sets
(mixes of well-squeezable sources and not squeezable binaries), which is 
usual
environment for Gentoo people.
For media-files the default heuristics works very bad (is it clear, why 
so?).
For large files it is strongly recommended to dedicate a separate 
partition without
compression (mkfs option "create=reg40").

Thanks,
Edward.

On 07/27/2016 08:39 PM, Georgios Tsalikis wrote:
> Here is my disappointing data :p
>
> # measurefs.reiser4 -p /dev/sdc3
> measurefs.reiser4 1.1.0
> Format release: 4.0.1
> Copyright (C) 2001-2005 by Hans Reiser, licensing governed by 
> reiser4progs/COPYING.
>
> Default profile:
> create:          "ccreg40"         (id:0x4 type:0x0)    [Regular file 
> plugin for creat(2)]
> key:             "key_large"       (id:0x1 type:0xb)    [Key plugin]
> node:            "node40"          (id:0x0 type:0x2)    [Node plugin]
> compress:        "lzo1"            (id:0x0 type:0xc) [Compression plugin]
> compressMode:    "conv"            (id:0x4 type:0xd) [Compression Mode 
> plugin]
> cluster:         "64K"             (id:0x0 type:0x10)    [Cluster plugin]
> hash:            "r5_hash"         (id:0x1 type:0x3)    [Directory 
> entry hash plugin]
> fibration:       "ext_1_fibre"     (id:0x2 type:0x4)    [Key fibration 
> plugin]
> formatting:      "smart"           (id:0x2 type:0x5)    [File body 
> formatting plugin]
>
> (actually i formatted it with node41 but it doesn't appear so)
>
> # ls -l resstick.dd
> -rw-r--r-- 1 root root 22007840768 Ιούλ 26 15:03 resstick.dd
> # time rm resstick.dd
>
> real    21m43.005s
> user    0m0.000s
> sys    5m2.132s
>
> If this is not problematic then what is? It is a single deletion!!
>
>
> On 27/07/2016 09:15 μμ, Morgan Smith wrote:
>> Was the file system created using the reg40 plugin or ccreg40 for on the
>> fly compression?
>>
>> It seems to me I had this issue when using ccreg40 for on the fly
>> compression. I wrote a similar request for help some years ago and I
>> believe the answer was to not use compression. IIRC it's not an issue
>> with the compression itself rather the handling of allocated space for
>> it and the shuffling that is done when releasing resources. I was unable
>> to quickly find my old email to the list to confirm :(
>>
>> On 07/27/2016 11:51 AM, Georgios Tsalikis wrote:
>>> It is almost always like this. For example a directory with 2.5GB of
>>> large files takes about 2 minutes. Right now i am deleting a large
>>> directory with small files, I didn't keep the numbers before running,
>>> but they are many directories with source code. Could it be
>>> fragmentation? And how could I mitigate it? Thanks
>>>
>>>
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe
>>> reiserfs-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> reiserfs-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reiser4 extremely slow at deleting.

[Georgios Tsalikis]

Thanks for responding Edward.

That resstick.dd is a dd image of a thumbdrive with an operating system 
and some media files in it.
Now... i deleted another file. A backup of my $HOME. Approximately 70GB 
and it took a second or two.
Next is another dd of a whole Btrfs . Let's see how it deletes. In the 
meanwhile I am fscking because that last deletion caused free space to 
shrink. I will post separately about it.

On 27/07/2016 10:24 μμ, Edward Shishkin wrote:
> By default compression is turned on, and the file system tries to be 
> "smart".
> However, default heuristics is not perfect. It works well for "/" 
> (setups created
> during system installation). Also it works fine for various 
> development sets
> (mixes of well-squeezable sources and not squeezable binaries), which 
> is usual
> environment for Gentoo people.
> For media-files the default heuristics works very bad (is it clear, 
> why so?).
> For large files it is strongly recommended to dedicate a separate 
> partition without
> compression (mkfs option "create=reg40").
>
> Thanks,
> Edward.
>
> On 07/27/2016 08:39 PM, Georgios Tsalikis wrote:
>> Here is my disappointing data :p
>>
>> # measurefs.reiser4 -p /dev/sdc3
>> measurefs.reiser4 1.1.0
>> Format release: 4.0.1
>> Copyright (C) 2001-2005 by Hans Reiser, licensing governed by 
>> reiser4progs/COPYING.
>>
>> Default profile:
>> create:          "ccreg40"         (id:0x4 type:0x0)    [Regular file 
>> plugin for creat(2)]
>> key:             "key_large"       (id:0x1 type:0xb)    [Key plugin]
>> node:            "node40"          (id:0x0 type:0x2)    [Node plugin]
>> compress:        "lzo1"            (id:0x0 type:0xc) [Compression 
>> plugin]
>> compressMode:    "conv"            (id:0x4 type:0xd) [Compression 
>> Mode plugin]
>> cluster:         "64K"             (id:0x0 type:0x10) [Cluster plugin]
>> hash:            "r5_hash"         (id:0x1 type:0x3) [Directory entry 
>> hash plugin]
>> fibration:       "ext_1_fibre"     (id:0x2 type:0x4)    [Key 
>> fibration plugin]
>> formatting:      "smart"           (id:0x2 type:0x5)    [File body 
>> formatting plugin]
>>
>> (actually i formatted it with node41 but it doesn't appear so)
>>
>> # ls -l resstick.dd
>> -rw-r--r-- 1 root root 22007840768 Ιούλ 26 15:03 resstick.dd
>> # time rm resstick.dd
>>
>> real    21m43.005s
>> user    0m0.000s
>> sys    5m2.132s
>>
>> If this is not problematic then what is? It is a single deletion!!
>>
>>
>> On 27/07/2016 09:15 μμ, Morgan Smith wrote:
>>> Was the file system created using the reg40 plugin or ccreg40 for on 
>>> the
>>> fly compression?
>>>
>>> It seems to me I had this issue when using ccreg40 for on the fly
>>> compression. I wrote a similar request for help some years ago and I
>>> believe the answer was to not use compression. IIRC it's not an issue
>>> with the compression itself rather the handling of allocated space for
>>> it and the shuffling that is done when releasing resources. I was 
>>> unable
>>> to quickly find my old email to the list to confirm :(
>>>
>>> On 07/27/2016 11:51 AM, Georgios Tsalikis wrote:
>>>> It is almost always like this. For example a directory with 2.5GB of
>>>> large files takes about 2 minutes. Right now i am deleting a large
>>>> directory with small files, I didn't keep the numbers before running,
>>>> but they are many directories with source code. Could it be
>>>> fragmentation? And how could I mitigate it? Thanks
>>>>
>>>>
>>>> -- 
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> reiserfs-devel" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe 
>>> reiserfs-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> reiserfs-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html