Thanks Mark, That was my understanding from the SSC spec too, though I am not a tape guy. So, this means that the behaviour in the patch is standards compliant, and also what physical devices do. Destage to physical medium is only guaranteed to be completed once the WRITE-FILEMARK has finished. So we dont need to add any controls to activate/deactivate this new behaviour. We can just apply the current patch as-is and that is all we need to do. regards ronnie sahlberg On Sun, Jan 22, 2012 at 12:54 AM, Mark Harvey <markh794@xxxxxxxxx> wrote: > I don't have the specs handy, but if memory serves me correctly, real tape drives behave the same way. i.e. a write filemark will force a flush. Even if the filemark count = 0 > > Sent from my iPad > > On Jan 21, 2012, at 22:56, Gabriele <gabriele.mailing@xxxxxxxxxxx> wrote: > >> Hello, >> >>> The patch does improve performance significantly, especially on >>> slow/low-end/dodgy hardware where fsync is expensive. >> >> I strongly agree with this patch. On my low end hardware performance was >> about 2MB/s. Removing fsync() jumped to more than 60 MB/s. >> The suggested behavior is safe enough for a tape activity. Even with >> physical tapes, I believe that in case of a system crash or power loss, >> the effects will be the same or worst ... >> Thumbs up for its integration in the mainline code. >> >> -- >> Gabriele >> -- >> To unsubscribe from this list: send the line "unsubscribe stgt" 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 stgt" 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 stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
