Comments on: OCFS2: Unappreciated Linux File System http://www.linux-mag.com/id/7809/ Open Source, Open Standards Sat, 05 Oct 2013 13:48:18 +0000 hourly 1 http://wordpress.org/?v=3.1 By: shaik http://www.linux-mag.com/id/7809/#comment-208179 shaik Thu, 03 May 2012 20:35:55 +0000 http://www.linux-mag.com/id/7809/#comment-208179 name, status, max(start_time) start_time,max(end_time) end_time from RC_RMAN_BACKUP_JOB_DETAILS b where start_time < sysdate -1 group by db_name,status ) backup_type, (select db_name,command_id, max(start_time) start_time, max(end_time) end_time from RC_RMAN_BACKUP_JOB_DETAILS B WHERE start_time < sysdate -1 group by db_name,command_id) backup_status , (select db_name,time_taken_display, max(start_time) start_time, max(end_time) end_time from RC_RMAN_BACKUP_JOB_DETAILS B WHERE end_time < sysdate -1 group by db_name,time_taken_display ) backup_duration, (select db_name,input_bytes, max(start_time) start_time, max(end_time) end_time from RC_RMAN_BACKUP_JOB_DETAILS B WHERE end_time < sysdate -1 group by db_name,input_bytes) input_bytes, (select db_name,output_bytes, max(start_time) start_time, max(end_time) end_time from RC_RMAN_BACKUP_JOB_DETAILS B WHERE end_time < sysdate -1 group by db_name,output_bytes) output_bytes where maxdt.db_name = backup_status.db_name and maxdt.db_name = backup_type.db_name and maxdt.start_time = backup_status.start_time and maxdt.start_time = backup_duration.start_time and maxdt.start_time = input_bytes.start_time and maxdt.start_time = output_bytes.start_time and maxdt.start_time = backup_type.start_time) backups where dbs.db_name = backups.db_name (+) name, status, max(start_time) start_time,max(end_time) end_time
from RC_RMAN_BACKUP_JOB_DETAILS b
where start_time < sysdate -1
group by db_name,status ) backup_type,
(select db_name,command_id, max(start_time) start_time, max(end_time) end_time
from RC_RMAN_BACKUP_JOB_DETAILS B
WHERE start_time < sysdate -1
group by db_name,command_id) backup_status ,
(select db_name,time_taken_display, max(start_time) start_time, max(end_time) end_time
from RC_RMAN_BACKUP_JOB_DETAILS B
WHERE end_time < sysdate -1
group by db_name,time_taken_display ) backup_duration,
(select db_name,input_bytes, max(start_time) start_time, max(end_time) end_time
from RC_RMAN_BACKUP_JOB_DETAILS B
WHERE end_time < sysdate -1
group by db_name,input_bytes) input_bytes,
(select db_name,output_bytes, max(start_time) start_time, max(end_time) end_time
from RC_RMAN_BACKUP_JOB_DETAILS B
WHERE end_time < sysdate -1
group by db_name,output_bytes) output_bytes
where maxdt.db_name = backup_status.db_name
and maxdt.db_name = backup_type.db_name
and maxdt.start_time = backup_status.start_time
and maxdt.start_time = backup_duration.start_time
and maxdt.start_time = input_bytes.start_time
and maxdt.start_time = output_bytes.start_time
and maxdt.start_time = backup_type.start_time) backups
where dbs.db_name = backups.db_name (+)

]]> By: shaik http://www.linux-mag.com/id/7809/#comment-207081 shaik Wed, 02 May 2012 20:41:02 +0000 http://www.linux-mag.com/id/7809/#comment-207081 excellant excellant

]]> By: tedkozma http://www.linux-mag.com/id/7809/#comment-8550 tedkozma Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7809/#comment-8550 <br />

]]> By: chammitt http://www.linux-mag.com/id/7809/#comment-8551 chammitt Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7809/#comment-8551 <p>http://wiki.samba.org/index.php/CTDB_Setup#Other_cluster_filesystems </p> http://wiki.samba.org/index.php/CTDB_Setup#Other_cluster_filesystems

]]> By: txster http://www.linux-mag.com/id/7809/#comment-8552 txster Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7809/#comment-8552 <p>One things I\'ve seen OCFS2 bad at is dealing with tons of small files that change a lot. A client has setup OCFS2 on two nodes to store the company\'s mail system, storing data in a Maildir structure. After 3-4 months (and this is a rather small, <50 ppl, place) it just stops working! After troubleshooting we\'ve found out that the OCFS2 can\'t allocate its own \'inodes\' anymore. Usually it auto extends, but it needs 1M of contiguous space to do it... Apparently the fs was so fragmented that this was impossible ! A bit annoying, to say the least. </p> One things I\’ve seen OCFS2 bad at is dealing with tons of small files that change a lot. A client has setup OCFS2 on two nodes to store the company\’s mail system, storing data in a Maildir structure. After 3-4 months (and this is a rather small, <50 ppl, place) it just stops working! After troubleshooting we\’ve found out that the OCFS2 can\’t allocate its own \’inodes\’ anymore. Usually it auto extends, but it needs 1M of contiguous space to do it… Apparently the fs was so fragmented that this was impossible ! A bit annoying, to say the least.

]]> By: zapman449 http://www.linux-mag.com/id/7809/#comment-8553 zapman449 Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7809/#comment-8553 <p>OCFS2 v1.4.x seems to work great for large files, and small files that don\'t change much. But if you\'re in a small file, high turnover situation, there are some nasty fragmentation bugs out there. You need to be ready to track the latest linux kernels, and also be prepared to rebuild your filesystems. </p> OCFS2 v1.4.x seems to work great for large files, and small files that don\’t change much. But if you\’re in a small file, high turnover situation, there are some nasty fragmentation bugs out there. You need to be ready to track the latest linux kernels, and also be prepared to rebuild your filesystems.

]]> By: jtmcdole http://www.linux-mag.com/id/7809/#comment-8554 jtmcdole Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7809/#comment-8554 <p>There wasn\'t any mention of distributed parity or other forms of data protection if a node goes down. Does OCFS2 support this? </p> There wasn\’t any mention of distributed parity or other forms of data protection if a node goes down. Does OCFS2 support this?

]]> By: elielmsouza http://www.linux-mag.com/id/7809/#comment-8555 elielmsouza Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7809/#comment-8555 <p>Well, we use OCFS2 with 5 nodes. We received 200.000 files per day with 8k of size. Our biggest problem was fragmentation, but creating inodes to full the inodes table works very well.<br /> Did two years we have implemented OCFS2.<br /> Excuse my poor English.... </p> Well, we use OCFS2 with 5 nodes. We received 200.000 files per day with 8k of size. Our biggest problem was fragmentation, but creating inodes to full the inodes table works very well.
Did two years we have implemented OCFS2.
Excuse my poor English….

]]> By: alcachi http://www.linux-mag.com/id/7809/#comment-8556 alcachi Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7809/#comment-8556 <p>One of the great advantages of OCFS2 is that it supports mounting loopback images. Several years ago we tried to set up GFS and came into this issue because it did not support this feature. Basically this meant that we could not run Xen virtual machine images from there. Then we discovered OCFS2, it was easier to set up and it allowed us to run our Xen VM directly from there.</p> <p>Being a clustered filesystem it also allowed us to do live migration of virtual machines between different servers, what was also great. </p> One of the great advantages of OCFS2 is that it supports mounting loopback images. Several years ago we tried to set up GFS and came into this issue because it did not support this feature. Basically this meant that we could not run Xen virtual machine images from there. Then we discovered OCFS2, it was easier to set up and it allowed us to run our Xen VM directly from there.

Being a clustered filesystem it also allowed us to do live migration of virtual machines between different servers, what was also great.

]]>