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
