Yes and without the trailing nulls. Florin Andrei wrote: > So what would happen if we use 1.4 instead? Would the logger keep > logging data and the user would be able to read the new lines normally > while node A is down? > > > On 03/30/2010 11:42 AM, Sunil Mushran wrote: > >> What you are seeing is the result of writeback data journaling >> in ocfs2 1.2. In ocfs2 1.4, we default to ordered data journaling. >> Refer to the 1.4 user's guide for more. >> >> Florin Andrei wrote: >> >>> A and B are identical machines. Network has lots of redundancy. They >>> both access same OCFS2 volumes over Fiber Channel on a SAN. >>> >>> Red Hat Enterprise Linux Server release 5.3 (Tikanga) >>> 2.6.18-128.el5 x86_64 >>> OCFS2 1.2.9 >>> >>> There's a software appending lines to some log files on a SAN volume >>> shared by both nodes. Either system can write to the log files. >>> >>> As a redundancy test, I cut off power to node A while doing transactions >>> on the site (sudden cut-off, no graceful shutdown). While logged in to >>> node B, I noticed some log files appeared to be filled with NULL (00 >>> hex) characters at the end. >>> >>> When I powered node A back on, the log files turned normal all of a >>> sudden. Looks like no logging data was lost, I could read the lines that >>> were logged while A was down. >>> >>> It's just during the power shutdown on node A, the files appeared padded >>> with NULL at the end on node B, but turned back normal when A came back >>> online. >>> >>> Is this something that can be fixed? >>> >>> >>> >> _______________________________________________ >> Ocfs2-users mailing list >> Ocfs2-users@oss.oracle.com >> http://oss.oracle.com/mailman/listinfo/ocfs2-users >> > > >
_______________________________________________ Ocfs2-users mailing list Ocfs2-users@oss.oracle.com http://oss.oracle.com/mailman/listinfo/ocfs2-users
