5 Sep
2011
5 Sep
'11
6:10 a.m.
HI!
Xwiki 3.1. Attachment versioning turned off. Storage is set to file system, Works fine
with relatively small files.
I uploaded 700M file - no problem, a bit to wait, but works fine.
I tried then to delete this file. The result was also successful, but took nearly 1.5
minutes to finish. Is there any way to run file operations faster?
Thanks a lot.
Dmitry Bakbardin.
5 Sep
5 Sep
8:35 p.m.
On 09/05/2011 12:10 AM, Haru Mamburu wrote:
HI!
Xwiki 3.1. Attachment versioning turned off. Storage is set to file system, Works fine
with relatively small files.
I uploaded 700M file - no problem, a bit to wait, but works fine.
I tried then to delete this file. The result was also successful, but took nearly 1.5
minutes to finish. Is there any way to run file operations faster?
Deleting an attachment will save the file in the attachment trash, which
means copying the file in another place. You could try to disable the
attachment trash to get a faster result, if you don't care about rolling
back deleted attachments.
The time spent seems reasonable given that it involves disk I/O and a
fairly large file. What could be done to improve responsiveness is to do
all the work in the background, i.e. just start the file copy process
and instantly resume the work. This means more work to ensure that
future requests affecting that file won't interfere in a bad way.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
9:28 p.m.
Thanks a lot for help,
No way to disable recycle bin. If some vandals would ruin content and delete attachments -
it would be lost without possibility to get it back.
Move operations usually take milliseconds despite of file size. By accident I found a
reason of such slow down: XE makes TWO copies of the file in recycle bin (in the file
storage).
Should I report it as a bug of file storage?
Kind regards,
Dmitry Bakbardin
05 сентября 2011, 22:35 от Sergiu Dumitriu <sergiu(a)xwiki.com>om>:
On 09/05/2011 12:10 AM, Haru Mamburu wrote:
HI!
Xwiki 3.1. Attachment versioning turned off. Storage is set to file system, Works fine
with relatively small files.
I uploaded 700M file - no problem, a bit to wait, but works fine.
I tried then to delete this file. The result was also successful, but took nearly 1.5
minutes to finish. Is there any way to run file operations faster?
Deleting an attachment will save the file in the attachment trash, which
means copying the file in another place. You could try to disable the
attachment trash to get a faster result, if you don't care about rolling
back deleted attachments.
The time spent seems reasonable given that it involves disk I/O and a
fairly large file. What could be done to improve responsiveness is to do
all the work in the background, i.e. just start the file copy process
and instantly resume the work. This means more work to ensure that
future requests affecting that file won't interfere in a bad way.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
9:51 p.m.
On 09/05/2011 03:28 PM, Haru Mamburu wrote:
Thanks a lot for help,
No way to disable recycle bin. If some vandals would ruin content and delete attachments
- it would be lost without possibility to get it back.
Move operations usually take milliseconds despite of file size. By accident I found a
reason of such slow down: XE makes TWO copies of the file in recycle bin (in the file
storage).
Should I report it as a bug of file storage?
Yes.
Kind regards,
Dmitry Bakbardin
05 сентября 2011, 22:35 от Sergiu Dumitriu<sergiu(a)xwiki.com>om>:
On 09/05/2011 12:10 AM, Haru Mamburu wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
HI!
Xwiki 3.1. Attachment versioning turned off. Storage is set to file system, Works fine
with relatively small files.
I uploaded 700M file - no problem, a bit to wait, but works fine.
I tried then to delete this file. The result was also successful, but took nearly 1.5
minutes to finish. Is there any way to run file operations faster?
Deleting an attachment will save the file in the attachment trash, which
means copying the file in another place. You could try to disable the
attachment trash to get a faster result, if you don't care about rolling
back deleted attachments.
The time spent seems reasonable given that it involves disk I/O and a
fairly large file. What could be done to improve responsiveness is to do
all the work in the background, i.e. just start the file copy process
and instantly resume the work. This means more work to ensure that
future requests affecting that file won't interfere in a bad way.
4813
days inactive
4813
days old
3 comments
2 participants
participants (2)
-
Haru Mamburu -
Sergiu Dumitriu