Re: A USB HDD is trouble outbreak in debian7.7
Hi, all.
I think, the hardware of GLANTANK is obsolete.
The useful life of this product was end.
XScale can't get support of Intel and no one maintains that.
Intel XScale IOP Linux
http://xscaleiop.sourceforge.net/
http://sourceforge.net/projects/xscaleiop/files/
MAKAI is unrelated to NAS and ARM.
MAKAI is self-rebuildable LiveCD project.
MAKAI supports x86, ONLY.
It's Minimal system and not include NAS manager.
This problem seems to have 2 problems.
- XScale: The DMA function of XScale is not good. Intel failed to support it.
- Hard drive: There may be also a problem with function of a JBOD controller.
2015-01-06 9:43 GMT+09:00 Joel Rees <joel.rees@gmail.com>:
> GLANTANK is a gigabit version of LANTANK. IO-DATA's child company
> Chousensha (Challenger) produced these in response to the Kurobako
> (with which some here may be familiar).
>
> http://ja.wikipedia.org/wiki/GLAN_Tank
> http://translate.google.co.jp/translate?hl=en&sl=ja&u=http://ja.wikipedia.org/wiki/GLAN_Tank&prev=search
>
> http://ja.wikipedia.org/wiki/LAN_Tank
> http://translate.google.co.jp/translate?hl=en&sl=ja&u=http://ja.wikipedia.org/wiki/GLAN_Tank&prev=search
>
> These are customizable NAS units, apparently running a customized
> debian (MAKAI -- MAKe Again ISO Image) internally.
>
> http://makai.sourceforge.jp/wiki/index.php?FrontPage
> http://translate.google.co.jp/translate?hl=en&sl=ja&u=http://ja.wikipedia.org/wiki/GLAN_Tank&prev=search
>
> LANTANK had an SH4 cpu, but the GLANTANK has an ARM (XScale).
>
> On Mon, Jan 5, 2015 at 9:22 AM, Jun Itou <itou_jun@infoseek.jp> wrote:
>> I managed debian 7 by the following constitution.
>>
>> Body) I-O DATA GLANTANK 2.0TB (500GB * 4 RAID0, iop32x)
>> USB1) I-O DATA HDZ-UES 2.0TB (500GB * 4 JBOD)
>> USB2) I-O DATA HDZ-UES 1.0TB (250GB * 4 JBOD)
>> USB3) I-O DATA HDZ-UES 1.0TB (250GB * 4 JBOD)
>> USB4) I-O DATA HDW-UE 1.0TB (500GB * 2 JBOD)
>>
>> After making 7.7 from debian 7.6, malfunction occurred.
>>
>> 1) A sector error occurs when I do mount and becomes the lead only
>> 2) I fail in synchronization of the file system when I do fdisk
>>
>> I gave following tests to cut a problem into pieces.
>>
>> 1) I do operation same as GLANTANK in x64 environment whether it is a problem of the hardware.
>> -> Because the same problem occurs with both, it is not peculiar to hardware.
>>
>> 2) I confirm whether it is the problem of the HDD of USB1 - 4 with the test tool of the HDD maker.
>> -> Because the HDD of all passed a test, it is not a problem of USB1 - 4.
>>
>> 3) I do the same operation in Fedora whether it is a problem peculiar to debian.
>> -> Because it reappeared in Fedora, I conclude it to be a problem of kernel.
>>
>> 4) I change a version of kernel on debian and do the same operation.
>> -> 3.2.62 : It does not reappear
>> 3.2.63 ~ : Reappear
>> 3.18.0 ~ : Reappear
>>
>> 5) I report it to kernel.org and do the same operation after enforcement in the end run which there was of the answer.
>> -> Please refer to https://bugzilla.kernel.org/show_bug.cgi?id=89511.
>
> The summary here is that the GLANTANK seems not to like the
> SYNCHRONIZE CACHE command.
>
> 話をまとめると GLANTANK が SYNCHRONIZE CACHE の命令に応じないようです。
>
> https://bugzilla.kernel.org/show_bug.cgi?id=89511#c35
>
> Alan Stern says that the kernel should be able to handle this in 3.18
> or later, but Jun indicates that 3.18 does not handle it yet.
>
> スターン氏によると、カーネルの 3.18 なら対処できるであろう、ということでした。その反面、 JunItou の結果はそうではなかった。
>
>> It is to say that my USB HDD cannot support the change of this journal function in conclusion.
>> I make kernel latest or seem to but make a USB HDD a different one if I continue managing it by the present constitution.
>>
>> I knew that it was not developed debian 8 for GLANTANK by a document.
>> Because there is no help for it, I think to manage it without formating ext2, and using the journal function.
>>
>> ※In addition, one of file system is destroyed when an error happens as for this malfunction even once.
>> I hope that it reappears and is not given a test with the contained HDD of important data.
>>
>> ※Because the funny grammar is machine translation; a pardon
>>
>> That's all.
>
> I'm thinking that the best place to fix this would be in the MAKAI
> community, but, as I check back in the Japanese list from last month,
> it looks like Jun has already tried contacting them. And that
> community seems to be an abandoned sourceforge.jp project, completely
> untouched since 2010. And the Makai project doesn't seem to have a
> place to post bugs.
>
> https://lists.debian.org/debian-japanese/2014/12/msg00003.html
>
> 簡単に考えたら、 MAKAIのコミュニティに連絡した方が速い、かな？と思うけど、先月の日本のメールリスとを見直したら、もう、連絡されているのではないですか？それに、2010年からはプロジェクトが完全ほったらかしの様子ですね。さらに、バッグの窓口がなさそうです。
>
> it appears that last month I seem to have found something that made it
> look to me like the once-maintainer of MAKAI, kin-neko, has
> more-or-less washed his hands of a ten-year-old project that never
> developed a self-sustaining community. I don't remember where I found
> that, however.
>
> 先月の投稿に、僕がどこかで見つけた情報のため、 MAKAI管理者の kinneko
> は十年前の世界の遺跡のように、手放しの姿勢となっているように思いました。コミュニティが成立できなかったためでしょう。ただし、その情報はどこで手に入れたかは覚えていません。
>
> Anybody here in user, arm, or embedded (or d-japanese) have a suggestion?
>
> Joel Rees
>
> Be careful when you look at conspiracy.
> Look first in your own heart,
> and ask yourself if you are not your own worst enemy.
> Arm yourself with knowledge of yourself, as well.
>
>
> --
> To UNSUBSCRIBE, email to debian-arm-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: https://lists.debian.org/CAAr43iOLR5ibR-VFQE4gx9afV3gWMm+kHTsuESYLRvd1GMaOw@mail.gmail.com
>
Reply to: