Re: [Aoetools-discuss] vblade chs boundary warning
Brought to you by:
ecashin,
elcapitansam
Menu
▾
▴
Re: [Aoetools-discuss] vblade chs boundary warning
|
From: Catalin S. <cs...@us...> - 2015-02-25 12:50:25
|
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
>>>
>
>
|
