Hi Dushan, I think it won't affect the responsiveness. That mount option is for txnmgrd daemon, which just wakes up once in (10 minutes?) and checks if transactions are too large or too old. Actually, this is the process spawning a transaction (->write(), ->truncate(), etc) who is responsible for active suppression of that transaction. If someone spawns a 4G transaction, then it is incorrect, so feel free to make _him_ check the transaction size in accordance with your thoughts about RAM/disk sizes in modern machines. Thanks, Edward. On 12/24/2016 08:19 PM, Dušan Čolić wrote:
Currently tmgr.atom_max_size defaults to 1/4 of RAM. Historically RAM size increased faster than disk write speeds so machines today usually ship with 4-16GB of RAM that means that we can get to situation where we have to flush 1-4GB of data and while doing so system would be unresponsive for minutes for apps that wait on sync. If we presume an optimistic scenario of 100MB/s write speed and 10sec wait time for 16GB RAM we come to the 1/16 ratio. Your thoughts? Dushan -- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
-- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
