Thanks for your response. Yes, the rsync copies a number of the 2GB files 
written by the same database software on another system on XFS, and compression 
is successful. These files consist mostly of plain text log output and are 
highly compressible (4:1 via zlib). When the database is running locally on 
btrfs, the I/O pattern is that the database allocates a new 2GB datafile 
(perhaps using a sparse allocation call, I know it does on XFS) and then says 
it fills the file with zeroes (but I'm not certain this actually happens). At 
that point database inserts are appended initially to a transaction log (a 
separate non-sparse 2GB file), and shortly thereafter there is a batch copy 
operation (I'm not sure of the size) of a set of new rows which are copied from 
the transaction log and appended to the main datafiles (which are sparse). Up 
until now I have included both the transaction log and the datafiles within the 
btrfs filesystem - next I'm going to try putting the transaction log on a 
separate filesystem . The btrfs fi df output was taken after the database load 
process was stopped, so it reflects a static set of the 2GB datafiles (plus the 
transaction log and a few other database system files).

-----Original Message-----
From: Liu Bo [mailto:[email protected]] 
Sent: Tuesday, December 04, 2012 7:02 PM
To: Thorn Roby
Cc: [email protected]
Subject: Re: Mounted compress-force=zlib, compresses when files copied in, but 
not when written directly by application


Well, it shouldn't be that since we have compress-force, as the name shows, 
with compress-force it'll always try to compress the data via zlib/lzo.

So the previous rsync one is just 'write numbers of 2G files', while the 
current application one is 'write numbers of 2G files' plus 'overwritten by 
others later', is it right?

And is the above 'btrfs fi df' output captured after 'overwritten', or not?

thanks,


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to