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 <csalgau@xxxxxxxxxxxxxxxxxxxxx> 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
>>>>> Aoetools-discuss@xxxxxxxxxxxxxxxxxxxxx
>>>>> 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
>>>> Aoetools-discuss@xxxxxxxxxxxxxxxxxxxxx
>>>> https://lists.sourceforge.net/lists/listinfo/aoetools-discuss
>>>
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Aoetools-discuss mailing list
Aoetools-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/aoetools-discuss
