[xwiki-users] Status of filesystem attachment storage.
Hi. Could anyone, please, give any info about status of filesystem attachment storage? Is it stable? Does it deal with non-ascii filenames prolerply? If so - why in 3.4 versions default storage for attachments will be hibernate? Cheers, R. --
On Jan 24, 2012, at 10:37 PM, Ryszard Łach wrote:
Hi.
Could anyone, please, give any info about status of filesystem attachment storage?
Is it stable?
Caleb can probably answer better here since he's the one who implemented this. My POV: * It's supposed to be usable * We need more real life reports that it's working fine in production * We've received some bug reports already. Several have been fixed, there might still be some open issues. You could search open issues about "filesystem" on http://jira.xwiki.org to know specific details * One current limitation I know is that clustering is not easily done since you need to cluster the filesystem. This can be achieved with a NFS mount for example.
Does it deal with non-ascii filenames prolerply?
No idea. Caleb?
If so - why in 3.4 versions default storage for attachments will be hibernate?
Filesystem storage is not a perfect solution: * clustering issue mentioned above * it makes it harder to backup your XWiki system since you need to backup not only the DB but also the directory where the attachments are saved. It's nice to know that everything is in the DB. * the filesystem is one additional point of failure Ideally we would not need filesystem storage at all since DBs should be able to stream arbitrary data in a performant manner. In practice only some DBs support this (MySQL doesn't AFAIK). All that said I completely agree with your question. I'd also like that we answer it better and that we post this status on xwiki.org. So guys, can you complement/correct what I've said above so that we can get a correct statement about this feature? :) Thanks -Vincent
It's stable from my POV. It's being used in production on http://planete.sankore.org Ludovic 2012/1/24 Vincent Massol <vincent@massol.net>
On Jan 24, 2012, at 10:37 PM, Ryszard Łach wrote:
Hi.
Could anyone, please, give any info about status of filesystem attachment storage?
Is it stable?
Caleb can probably answer better here since he's the one who implemented this.
My POV: * It's supposed to be usable * We need more real life reports that it's working fine in production * We've received some bug reports already. Several have been fixed, there might still be some open issues. You could search open issues about "filesystem" on http://jira.xwiki.org to know specific details * One current limitation I know is that clustering is not easily done since you need to cluster the filesystem. This can be achieved with a NFS mount for example.
Does it deal with non-ascii filenames prolerply?
No idea. Caleb?
If so - why in 3.4 versions default storage for attachments will be hibernate?
Filesystem storage is not a perfect solution: * clustering issue mentioned above * it makes it harder to backup your XWiki system since you need to backup not only the DB but also the directory where the attachments are saved. It's nice to know that everything is in the DB. * the filesystem is one additional point of failure
Ideally we would not need filesystem storage at all since DBs should be able to stream arbitrary data in a performant manner. In practice only some DBs support this (MySQL doesn't AFAIK).
All that said I completely agree with your question. I'd also like that we answer it better and that we post this status on xwiki.org.
So guys, can you complement/correct what I've said above so that we can get a correct statement about this feature? :)
Thanks -Vincent _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Ludovic, I knew it's used there so I tried to answer the question about the international-character-set of the file-names. I think the answer is no because I uploaded: http://planete.sankore.org/xwiki/bin/view/Coll_polx/lecielbleuteX with the tile "le ciel bleuté ¬X>λω" and with the filename: "le ciel bleuté ¬X>λω.png" However, my resource got named lecielbleuteX and the filename as well. After that I tried with viewer=attachments and again all characters got "wersternalized"... It would be interesting to know if this was intended. paul Le 24 janv. 2012 à 23:32, Ludovic Dubost a écrit :
It's stable from my POV. It's being used in production on http://planete.sankore.org
Ludovic
2012/1/24 Vincent Massol <vincent@massol.net>
On Jan 24, 2012, at 10:37 PM, Ryszard Łach wrote:
Hi.
Could anyone, please, give any info about status of filesystem attachment storage?
Is it stable?
Caleb can probably answer better here since he's the one who implemented this.
My POV: * It's supposed to be usable * We need more real life reports that it's working fine in production * We've received some bug reports already. Several have been fixed, there might still be some open issues. You could search open issues about "filesystem" on http://jira.xwiki.org to know specific details * One current limitation I know is that clustering is not easily done since you need to cluster the filesystem. This can be achieved with a NFS mount for example.
Does it deal with non-ascii filenames prolerply?
No idea. Caleb?
If so - why in 3.4 versions default storage for attachments will be hibernate?
Filesystem storage is not a perfect solution: * clustering issue mentioned above * it makes it harder to backup your XWiki system since you need to backup not only the DB but also the directory where the attachments are saved. It's nice to know that everything is in the DB. * the filesystem is one additional point of failure
Ideally we would not need filesystem storage at all since DBs should be able to stream arbitrary data in a performant manner. In practice only some DBs support this (MySQL doesn't AFAIK).
All that said I completely agree with your question. I'd also like that we answer it better and that we post this status on xwiki.org.
So guys, can you complement/correct what I've said above so that we can get a correct statement about this feature? :)
Thanks -Vincent _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
On 01/24/2012 05:38 PM, Paul Libbrecht wrote:
Ludovic,
I knew it's used there so I tried to answer the question about the international-character-set of the file-names. I think the answer is no because I uploaded: http://planete.sankore.org/xwiki/bin/view/Coll_polx/lecielbleuteX with the tile "le ciel bleuté ¬X>λω" and with the filename: "le ciel bleuté ¬X>λω.png" However, my resource got named lecielbleuteX and the filename as well. After that I tried with viewer=attachments and again all characters got "wersternalized"...
It would be interesting to know if this was intended.
It's "normal", since non-ASCII characters in attachment filenames are supported starting with 3.4, while sankore is still on 3.1. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On 01/24/12 23:03, Vincent Massol wrote:
Ideally we would not need filesystem storage at all since DBs should be able to stream arbitrary data in a performant manner. In practice only some DBs support this (MySQL doesn't AFAIK).
Is postgresql one of the better ones (in this area)? R.
Hi, I had been playing with FS for quite a long time and must say, that it is almost ready for production: - Looks stable, major and minor bug fixes were made. - Since 3.4 it deals with non-ascii correctly. I checked it with Cyrillic on 3.4RC1. - If you would turn FS on, be aware, that recycle bin with FS works, BUT still we have http://jira.xwiki.org/browse/XWIKI-7399 So, I didn't manage to make it running. So, I just switched off recycle bin for attachments, because this bug makes deleted attachment unmanaged. :-(
If so - why in 3.4 versions default storage for attachments will be hibernate?
If you don't play with large attachments (like I do), for clusering and maintainance it would much easier to keep all attachments in DB. Traditionally it was DB :-) As for me, Attachments size is relatively huge and will make all system very slow very soon, so I use FS from the very beginning of the project. Kind Regards Dmitry 25 января 2012, 01:37 от Ryszard Łach <ryszard.lach@contium.pl>:
Hi.
Could anyone, please, give any info about status of filesystem attachment storage?
Is it stable? Does it deal with non-ascii filenames prolerply?
If so - why in 3.4 versions default storage for attachments will be hibernate?
Cheers,
R.
--
_______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
participants (6)
-
Haru Mamburu -
Ludovic Dubost -
Paul Libbrecht -
Ryszard Łach -
Sergiu Dumitriu -
Vincent Massol