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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
