Re: [Aoetools-discuss] vblade chs boundary warning
Brought to you by:
ecashin,
elcapitansam
Menu
▾
▴
Re: [Aoetools-discuss] vblade chs boundary warning
|
From: Ed C. <ed....@ac...> - 2015-02-26 03:23:20
|
Great! After merging, I made a pre-release: https://github.com/ecashin/vblade/releases/tag/v23-rc1 On 02/25/2015 07:50 AM, Catalin Salgau wrote: > As requested, I've opened a pull request for this. > I have not included the full explanation in the man page as I believe > that is for initiators to work on, not targets. > I'm open to further changes. > Thanks! > > On 21/02/2015 3:45 AM, Ed Cashin wrote: >> These days, when something appears not to be working, people Google. >> >> So we've already done a lot by putting information that they can find on >> the mailing list. >> >> The original email was almost exactly what someone would need to find >> when they Google: A succinct, well founded, specific explanation of the >> danger and what can be done to avoid it. If that explanation is in the >> vblade documentation, it will be even easier to find with a web search. >> >> And really, that's what the documentation is for. The fact that people >> don't read documentation isn't a good reason to make noisy tools. Then >> they'll ignore the noise just like they ignore the documentation. ;) >> >> If nobody really has time to do a pull request with a documentation >> update based on the contents of the original email, I'll do it in a >> week. >> >> On 02/19/2015 08:10 AM, Catalin Salgau wrote: >>> I tend to be of the same opinion, with the added note that I knew >>> about the alignment differences prior to debugging this and we still >>> fell for it. I doubt that a warning in a man page would come to mind >>> (or really match what one would be looking for) when a user notices >>> corruption issues in running systems. >>> A log warning also has the added benefit that it can provide a >>> straight-forward value to truncate against. >>> @Ed: I'm not rigid regarding this and it's your call; however, I lack >>> the time to provide pull requests for any of these at the moment, and >>> the code I provided wasn't tested (we currently apply that correction >>> externally, but it's essentially the same and it's not hard to follow) >>> >>> >>> On 19/02/2015 6:39 AM, Joshua J. Kugler wrote: >>>> You might argue that people are more likely to read the logs than the >>>> docs...but then, a lot of people read neither until something goes >>>> wrong. But >>>> maybe finding that message in the logs is more likely to happen when >>>> something >>>> goes wrong, rather than "Hmm, something is wrong, I think I'll go >>>> look for >>>> warnings in the docs." >>>> >>>> But maybe that's just me. :) >>>> >>>> j >>>> >>>> On Wednesday, February 18, 2015 22:51:47 Ed Cashin wrote: >>>>> Would you consider a pull request that includes an addition to the >>>> documentation? That seems like a more appropriate place for a >>>> warning. On Feb >>>> 18, 2015 10:01 PM, Catalin Salgau <cs...@us...> >>>> wrote: >>>>>> Hi. >>>>>> >>>>>> While I haven't gotten around to testing any of the "recent" >>>>>> changes, a >>>>>> colleague finally tracked down one of our long-standing corruption >>>>>> issues some time ago and I think I should suggest a change that >>>>>> might >>>>>> help others. >>>>>> WinAoE has some code in the GettingsSize state that truncates a >>>>>> disk to >>>>>> CHS geometry. Prior to Vista, Windows enforced CHS alignment for >>>>>> partition boundaries, so this was not a problem. >>>>>> However, if you installed a newer OS (one using 1MB boundaries) then >>>>>> moved it to AoE storage, truncating at a partition boundary could >>>>>> cause >>>>>> sectors to be missing under WinAoE, corrupting your data. Windows >>>>>> probably never actually relied on this behaviour, since it was >>>>>> enforcing >>>>>> alignment itself. >>>>>> >>>>>> I would like to request a warning along the lines of (while the 512 >>>>>> byte >>>>>> sector size is superfluous, I include it for clarity) >>>>>> #define CHSALIGN 255*63*512 >>>>>> if ((size*512) % CHSALIGN) { >>>>>> vlong recsz = (size*512) + CHSALIGN - (size*512)%CHSALIGN; >>>>>> printf("Exported size (%llu) is not aligned to usual CHS >>>>>> geometry.\n", size*512) >>>>>> printf("Consider truncating to %llu bytes to prevent >>>>>> issues.\n", >>>>>> recsz); } >>>>>> Please excuse the lack of a pull request. >>>>>> I'll try getting back to the other changes I was proposing at a >>>>>> later >>>>>> time. >>>>>> Thanks! >>>>>> >>>>>> -------------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> ---- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT >>>>>> Server >>>>>> from Actuate! Instantly Supercharge Your Business Reports and >>>>>> Dashboards >>>>>> with Interactivity, Sharing, Native Excel Exports, App Integration >>>>>> & more >>>>>> Get technology previously reserved for billion-dollar corporations, >>>>>> FREE >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clkt >>>>>> >>>>>> >>>>>> rk _______________________________________________ >>>>>> Aoetools-discuss mailing list >>>>>> Aoe...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/aoetools-discuss >>>>> >>>>> ---------------------------------------------------------------------------- >>>>> >>>>> >>>>> -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>>>> from Actuate! Instantly Supercharge Your Business Reports and >>>>> Dashboards >>>>> with Interactivity, Sharing, Native Excel Exports, App Integration & >>>>> more >>>>> Get technology previously reserved for billion-dollar corporations, >>>>> FREE >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk >>>>> >>>>> >>>>> _______________________________________________ >>>>> Aoetools-discuss mailing list >>>>> Aoe...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/aoetools-discuss >>>> >> >> |
