* nilfs checkpoints tied to synchronous writes
@ 2012-06-26 1:11 Mark Trumpold
[not found] ` <CDB9B1D21E35BB4C9E8124D05FD86BB184ABA761A0-Nr8giE/DiON166AYIJghu6xOck334EZe@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Mark Trumpold @ 2012-06-26 1:11 UTC (permalink / raw)
To: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Hello,
I have a configuration where I use qemu/qcow loop filesystems
on top a nilfs filesystem to yield writeable snapshots.
The symptom I see is the nilfs filesystem "ballooning" in size when
writing large chunks of data to the qcow loop filesystem. I also see
_many_ nilfs checkpoints with small "NBLKINC" counts (>20 <50).
My working theory is nilfs creates checkpoints for each synchronous
write, and qcow insists on writing synchronously, thus the ballooning
of checkpoints.
One question is would it be possible to have nilfs not checkpoint so
often. I've tried the 'nilfs-tune -i ..' to no avail - apparently
synchronous writes overrule this setting.
Thanks in advance,
Mark T.
Confidentiality Notice: The information contained in this electronic e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and is confidential and/or privileged. If you and we have a confidentiality agreement or other non-disclosure obligations between us, this Notice shall be deemed to mark and identify the content of this email and any attachments as confidential and proprietary. If any reader of this communication is not the intended recipient, unauthorized use, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you.
IRS Circular 230 Disclosure: To ensure compliance with requirements imposed by the IRS, please be advised that any U.S. federal tax advice contained in this communication (including any attachments) is not intended or written to be used or relied upon, and cannot be used or relied upon, for the purpose of (i) avoiding penalties under the Internal Revenue Code, or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.
E-mail is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 5+ messages in thread[parent not found: <CDB9B1D21E35BB4C9E8124D05FD86BB184ABA761A0-Nr8giE/DiON166AYIJghu6xOck334EZe@public.gmane.org>]
* Re: nilfs checkpoints tied to synchronous writes [not found] ` <CDB9B1D21E35BB4C9E8124D05FD86BB184ABA761A0-Nr8giE/DiON166AYIJghu6xOck334EZe@public.gmane.org> @ 2012-06-27 6:16 ` Vyacheslav Dubeyko 2012-06-27 14:04 ` Mark Trumpold 0 siblings, 1 reply; 5+ messages in thread From: Vyacheslav Dubeyko @ 2012-06-27 6:16 UTC (permalink / raw) To: Mark Trumpold Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "; Vyacheslav.Dubeyko" Hi Mark, On Mon, 2012-06-25 at 18:11 -0700, Mark Trumpold wrote: > Hello, > > I have a configuration where I use qemu/qcow loop filesystems > on top a nilfs filesystem to yield writeable snapshots. > > The symptom I see is the nilfs filesystem "ballooning" in size when > writing large chunks of data to the qcow loop filesystem. I also see > _many_ nilfs checkpoints with small "NBLKINC" counts (>20 <50). > > My working theory is nilfs creates checkpoints for each synchronous > write, and qcow insists on writing synchronously, thus the ballooning > of checkpoints. I can cite man page for NILFS2: "When data is written or any change is made to a NILFS2 file system, it automatically creates a checkpoint. A checkpoint represents a consistent state of the NILFS2 file system of a certain instant.". > > One question is would it be possible to have nilfs not checkpoint so > often. I've tried the 'nilfs-tune -i ..' to no avail - apparently > synchronous writes overrule this setting. As you can see, checkpoint is a base technique of NILFS2 functioning. But you can manipulate by checkpoints during NILFS2 functioning by means of nilfs-cleanerd daemon. Do you use nilfs-cleanerd daemon? Please, read man page for nilfs-cleanerd daemon and its configuration file. I can cite man page: "nilfs_cleanerd is a system daemon which reclaims disk space of NILFS2 file system found in device." With the best regards, Vyacheslav Dubeyko. -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nilfs checkpoints tied to synchronous writes 2012-06-27 6:16 ` Vyacheslav Dubeyko @ 2012-06-27 14:04 ` Mark Trumpold [not found] ` <CC105D10.66F1%markt-PJstQz4BMNPR7s880joybQ@public.gmane.org> 0 siblings, 1 reply; 5+ messages in thread From: Mark Trumpold @ 2012-06-27 14:04 UTC (permalink / raw) To: Vyacheslav Dubeyko; +Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Hello Vyacheslav, Thank you for your reply. I have read the man page for nilfs_cleanerd and it's conf file, and have done quite a bit of experimentation. It does work as expected. After reading your email, and more thought I think that my problem case may have to be solved from the filesystem writer's side. I think what is happening is that 'qcow2' is forcing data to be flushed to disk on every write, instead of letting the kernel buffer into larger chunks. Thanks again for input. Best regards, Mark T. On 6/26/12 11:16 PM, "Vyacheslav Dubeyko" <slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org> wrote: >Hi Mark, > >On Mon, 2012-06-25 at 18:11 -0700, Mark Trumpold wrote: >> Hello, >> >> I have a configuration where I use qemu/qcow loop filesystems >> on top a nilfs filesystem to yield writeable snapshots. >> >> The symptom I see is the nilfs filesystem "ballooning" in size when >> writing large chunks of data to the qcow loop filesystem. I also see >> _many_ nilfs checkpoints with small "NBLKINC" counts (>20 <50). >> >> My working theory is nilfs creates checkpoints for each synchronous >> write, and qcow insists on writing synchronously, thus the ballooning >> of checkpoints. > >I can cite man page for NILFS2: >"When data is written or any change is made to a NILFS2 file system, it >automatically creates a checkpoint. A checkpoint represents a >consistent state of the NILFS2 file system of a certain instant.". > >> >> One question is would it be possible to have nilfs not checkpoint so >> often. I've tried the 'nilfs-tune -i ..' to no avail - apparently >> synchronous writes overrule this setting. > >As you can see, checkpoint is a base technique of NILFS2 functioning. >But you can manipulate by checkpoints during NILFS2 functioning by means >of nilfs-cleanerd daemon. > >Do you use nilfs-cleanerd daemon? > >Please, read man page for nilfs-cleanerd daemon and its configuration >file. I can cite man page: >"nilfs_cleanerd is a system daemon which reclaims disk space of NILFS2 >file system found in device." > >With the best regards, >Vyacheslav Dubeyko. > Confidentiality Notice: The information contained in this electronic e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and is confidential and/or privileged. If you and we have a confidentiality agreement or other non-disclosure obligations between us, this Notice shall be deemed to mark and identify the content of this email and any attachments as confidential and proprietary. If any reader of this communication is not the intended recipient, unauthorized use, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. IRS Circular 230 Disclosure: To ensure compliance with requirements imposed by the IRS, please be advised that any U.S. federal tax advice contained in this communication (including any attachments) is not intended or written to be used or relied upon, and cannot be used or relied upon, for the purpose of (i) avoiding penalties under the Internal Revenue Code, or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. E-mail is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <CC105D10.66F1%markt-PJstQz4BMNPR7s880joybQ@public.gmane.org>]
* Re: nilfs checkpoints tied to synchronous writes [not found] ` <CC105D10.66F1%markt-PJstQz4BMNPR7s880joybQ@public.gmane.org> @ 2012-06-27 21:14 ` Ryusuke Konishi [not found] ` <20120628.061420.04584589.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org> 0 siblings, 1 reply; 5+ messages in thread From: Ryusuke Konishi @ 2012-06-27 21:14 UTC (permalink / raw) To: Mark.Trumpold-PJstQz4BMNNBDgjK7y7TUQ Cc: slava-yeENwD64cLxBDgjK7y7TUQ, linux-nilfs-u79uwXL29TY76Z2rM5mHXA >On Mon, 2012-06-25 at 18:11 -0700, Mark Trumpold wrote: > Hello, > > I have a configuration where I use qemu/qcow loop filesystems > on top a nilfs filesystem to yield writeable snapshots. > > The symptom I see is the nilfs filesystem "ballooning" in size when > writing large chunks of data to the qcow loop filesystem. I also see > _many_ nilfs checkpoints with small "NBLKINC" counts (>20 <50). > > My working theory is nilfs creates checkpoints for each synchronous > write, and qcow insists on writing synchronously, thus the ballooning > of checkpoints. Hi Mark, thanks for your information. Did you try cache=writeback option on qemu ? Qemu looks to be using synchronous write operations heavily in its default cache mode. It's too expensive for underlying filesystems especially for nilfs. As you pointed out, synchronous write can be separated from checkpointing in theory. And, nilfs is partially applying such optimization by default (i.e. "order=relaxed" option). But the current optimization is not sufficient. I am actually thinking nilfs should have enhanced functionalilty which stops making checkpoints on data integrity operations like fsync or fdatasync. Unfortunately, it needs disk format extension to make it possible to recover data blocks written by fsync/fdatasync after unexpected shutdown/reboot. Garbage collector also has to handle such extension. So, these are one of todo items at present. Thanks, Ryusuke Konishi > On 6/26/12 11:16 PM, "Vyacheslav Dubeyko" <slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org> wrote: > > >Hi Mark, > > > >On Mon, 2012-06-25 at 18:11 -0700, Mark Trumpold wrote: > >> Hello, > >> > >> I have a configuration where I use qemu/qcow loop filesystems > >> on top a nilfs filesystem to yield writeable snapshots. > >> > >> The symptom I see is the nilfs filesystem "ballooning" in size when > >> writing large chunks of data to the qcow loop filesystem. I also see > >> _many_ nilfs checkpoints with small "NBLKINC" counts (>20 <50). > >> > >> My working theory is nilfs creates checkpoints for each synchronous > >> write, and qcow insists on writing synchronously, thus the ballooning > >> of checkpoints. > > > >I can cite man page for NILFS2: > >"When data is written or any change is made to a NILFS2 file system, it > >automatically creates a checkpoint. A checkpoint represents a > >consistent state of the NILFS2 file system of a certain instant.". > > > >> > >> One question is would it be possible to have nilfs not checkpoint so > >> often. I've tried the 'nilfs-tune -i ..' to no avail - apparently > >> synchronous writes overrule this setting. > > > >As you can see, checkpoint is a base technique of NILFS2 functioning. > >But you can manipulate by checkpoints during NILFS2 functioning by means > >of nilfs-cleanerd daemon. > > > >Do you use nilfs-cleanerd daemon? > > > >Please, read man page for nilfs-cleanerd daemon and its configuration > >file. I can cite man page: > >"nilfs_cleanerd is a system daemon which reclaims disk space of NILFS2 > >file system found in device." > > > >With the best regards, > >Vyacheslav Dubeyko. > > > > > > Confidentiality Notice: The information contained in this electronic e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and is confidential and/or privileged. If you and we have a confidentiality agreement or other non-disclosure obligations between us, this Notice shall be deemed to mark and identify the content of this email and any attachments as confidential and proprietary. If any reader of this communication is not the intended recipient, unauthorized use, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. > > IRS Circular 230 Disclosure: To ensure compliance with requirements imposed by the IRS, please be advised that any U.S. federal tax advice contained in this communication (including any attachments) is not intended or written to be used or relied upon, and cannot be used or relied upon, for the purpose of (i) avoiding penalties under the Internal Revenue Code, or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. > > E-mail is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <20120628.061420.04584589.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>]
* RE: nilfs checkpoints tied to synchronous writes [not found] ` <20120628.061420.04584589.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org> @ 2012-06-27 21:40 ` Mark Trumpold 0 siblings, 0 replies; 5+ messages in thread From: Mark Trumpold @ 2012-06-27 21:40 UTC (permalink / raw) To: Ryusuke Konishi Cc: slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org, linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Greetings Ryusuke, I'm floating on air at the moment, as I have a working solution. Turns out Stephene Chazelas had submitted bug at: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/595117 AND a small patch to 'qemu-nbd.c', which I applied and tested with great success. Since I'm only using the loop filesystem aspect of qemu, I couldn't use the 'cache=writeback' with the qemu VM tools, as you suggested. However, with the patch, I can submit the same logic to 'qemu-nbd --cache=writeback ..' Prior to the patch I would get >10k checkpoints by copying ~1/2gigbyte data to the loop device -- now I get 2-5 checkpoints -- I'm so stoked!! Thank you for your kind attention. NILFS rocks!! Regards, Mark T. -----Original Message----- From: Ryusuke Konishi [mailto:konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org] Sent: Wednesday, June 27, 2012 2:14 PM To: Mark Trumpold Cc: slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org; linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: nilfs checkpoints tied to synchronous writes >On Mon, 2012-06-25 at 18:11 -0700, Mark Trumpold wrote: > Hello, > > I have a configuration where I use qemu/qcow loop filesystems on top a > nilfs filesystem to yield writeable snapshots. > > The symptom I see is the nilfs filesystem "ballooning" in size when > writing large chunks of data to the qcow loop filesystem. I also see > _many_ nilfs checkpoints with small "NBLKINC" counts (>20 <50). > > My working theory is nilfs creates checkpoints for each synchronous > write, and qcow insists on writing synchronously, thus the ballooning > of checkpoints. Hi Mark, thanks for your information. Did you try cache=writeback option on qemu ? Qemu looks to be using synchronous write operations heavily in its default cache mode. It's too expensive for underlying filesystems especially for nilfs. As you pointed out, synchronous write can be separated from checkpointing in theory. And, nilfs is partially applying such optimization by default (i.e. "order=relaxed" option). But the current optimization is not sufficient. I am actually thinking nilfs should have enhanced functionalilty which stops making checkpoints on data integrity operations like fsync or fdatasync. Unfortunately, it needs disk format extension to make it possible to recover data blocks written by fsync/fdatasync after unexpected shutdown/reboot. Garbage collector also has to handle such extension. So, these are one of todo items at present. Thanks, Ryusuke Konishi > On 6/26/12 11:16 PM, "Vyacheslav Dubeyko" <slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org> wrote: > > >Hi Mark, > > > >On Mon, 2012-06-25 at 18:11 -0700, Mark Trumpold wrote: > >> Hello, > >> > >> I have a configuration where I use qemu/qcow loop filesystems on > >> top a nilfs filesystem to yield writeable snapshots. > >> > >> The symptom I see is the nilfs filesystem "ballooning" in size when > >> writing large chunks of data to the qcow loop filesystem. I also > >> see _many_ nilfs checkpoints with small "NBLKINC" counts (>20 <50). > >> > >> My working theory is nilfs creates checkpoints for each synchronous > >> write, and qcow insists on writing synchronously, thus the > >> ballooning of checkpoints. > > > >I can cite man page for NILFS2: > >"When data is written or any change is made to a NILFS2 file system, > >it automatically creates a checkpoint. A checkpoint represents a > >consistent state of the NILFS2 file system of a certain instant.". > > > >> > >> One question is would it be possible to have nilfs not checkpoint > >> so often. I've tried the 'nilfs-tune -i ..' to no avail - > >> apparently synchronous writes overrule this setting. > > > >As you can see, checkpoint is a base technique of NILFS2 functioning. > >But you can manipulate by checkpoints during NILFS2 functioning by > >means of nilfs-cleanerd daemon. > > > >Do you use nilfs-cleanerd daemon? > > > >Please, read man page for nilfs-cleanerd daemon and its configuration > >file. I can cite man page: > >"nilfs_cleanerd is a system daemon which reclaims disk space of > >NILFS2 file system found in device." > > > >With the best regards, > >Vyacheslav Dubeyko. > > > > > > Confidentiality Notice: The information contained in this electronic e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and is confidential and/or privileged. If you and we have a confidentiality agreement or other non-disclosure obligations between us, this Notice shall be deemed to mark and identify the content of this email and any attachments as confidential and proprietary. If any reader of this communication is not the intended recipient, unauthorized use, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. > > IRS Circular 230 Disclosure: To ensure compliance with requirements imposed by the IRS, please be advised that any U.S. federal tax advice contained in this communication (including any attachments) is not intended or written to be used or relied upon, and cannot be used or relied upon, for the purpose of (i) avoiding penalties under the Internal Revenue Code, or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. > > E-mail is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nilfs" > in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo > info at http://vger.kernel.org/majordomo-info.html Confidentiality Notice: The information contained in this electronic e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and is confidential and/or privileged. If you and we have a confidentiality agreement or other non-disclosure obligations between us, this Notice shall be deemed to mark and identify the content of this email and any attachments as confidential and proprietary. If any reader of this communication is not the intended recipient, unauthorized use, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. IRS Circular 230 Disclosure: To ensure compliance with requirements imposed by the IRS, please be advised that any U.S. federal tax advice contained in this communication (including any attachments) is not intended or written to be used or relied upon, and cannot be used or relied upon, for the purpose of (i) avoiding penalties under the Internal Revenue Code, or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. E-mail is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-06-27 21:40 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-06-26 1:11 nilfs checkpoints tied to synchronous writes Mark Trumpold
[not found] ` <CDB9B1D21E35BB4C9E8124D05FD86BB184ABA761A0-Nr8giE/DiON166AYIJghu6xOck334EZe@public.gmane.org>
2012-06-27 6:16 ` Vyacheslav Dubeyko
2012-06-27 14:04 ` Mark Trumpold
[not found] ` <CC105D10.66F1%markt-PJstQz4BMNPR7s880joybQ@public.gmane.org>
2012-06-27 21:14 ` Ryusuke Konishi
[not found] ` <20120628.061420.04584589.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2012-06-27 21:40 ` Mark Trumpold
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox