On 8/29/13 3:19 PM, Chris Murphy wrote: > > On Aug 29, 2013, at 1:53 PM, Hugo Mills <hugo@xxxxxxxxxxxxx> wrote: > >> On Thu, Aug 29, 2013 at 01:44:54PM -0600, Chris Murphy wrote: >>> >>> Certainly, if known for sure it won't be more than 30 seconds? >> >> Mmm... it'll depend on the setting of the commit period, which up >> until a couple of weeks ago was always 30s, but someone posted a patch >> to give it a config knob… > > > > "Proceeding will roll back the file system to a previous state, and > may cause the loss of successfully written data since the last commit > period (30 seconds by default). Proceed? (Y/N)" Is it just loss of data, or might this also result in a filesystem with inconsistent metadata, which then requires a fsck? Above sounds like it's "just" reverting to a previous (consistent) state. Is that correct? -Eric p.s. fwiw when the xfs_repair zero-log option "-L" is used, we say: "ALERT: The filesystem has valuable metadata changes in a log which is being\n" "destroyed because the -L option was used.\n")); -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
