Pavlos:
In realistic practical terms anything that involves customer's money is IMO BAD on a home grown FS solution (I'd rather use Oracle or something)
Is it because they are not transaction safe? Or just not robust enough?
OTOH a hit counters (and other type of counters) IMO is better at the FS level. Storing it in an RDBMS implies an extra no_hits_per_day_to_the_web_site going to the RDBMS.
Truely an advantage.
Also in many cases it is not that important if some hits are 'lost' ...
Why would you loose hits? What exactly would drop?
With file systems like RaiserFS or XFS
Been reading (Linux Technology Journal most recent issue (GFS in there too)) about these, and I will be fireing up Reiser when my SuSe 6.4 CD gets here. (Support the community with $ :) I don't know squat about Filesystems on a low level, but it really seems the blend of an RDBMS and is ideal.
on these it is be possible to have huge amounts of small objects in each directory (and still be efficient) and also provide journaling support (Seems to me they are essentially DBMS). It is possible (but probably difficult to implement) to have a RaiserFS Storage backend to ZODB. A better fit than an RDBMS backend because then you can take advantage of all the powerful FS tools like quota control, selective backups etc etc.
Yup. All my best, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.