何でも掲示板一括表示
［表示範囲：516〜522］［スレッドモード］

フォロー記事投稿

記事のキャンセル

皆さん、こんにちは！NKです。
昨日の日付けでBIGLOBEからメールが届いていました。内容は、
「ホームページエリア内不要ファイルの整理、もしくはご契約容量変更のお願い」
と、いうものでした。
え゛っ、このまえチェックした時は３ＭＢしか使ってなかったのに
と、思いながらよく読むと「現在のディスク容量算出方法では検出
できないものでした。」と、あります。どうも今までCGIによって
作成されたファイルがチェックされていなかった様なのです。
ってことは、会議室の記事全部！？
で、正確な容量はFTPですべてのファイルのバイト数をチェックし
て合計して下さいと・・。ちょっと非現実的では(^^;)
今まで深く考えずにTELENETやKingdomの容量チェックを信じて
きただけに、ちょっとショック。
いったい会議室だけで何ＭＢあるんだろう!?
少なくとも２ＭＢ以上あることは明らかになったけど・・・。

やっぱり容量増やすしか無いかな・・・。

フォロー記事投稿

記事のキャンセル

2月17日に、NKさんは書きました。

＞昨日の日付けでBIGLOBEからメールが届いていました。内容は、
＞「ホームページエリア内不要ファイルの整理、もしくはご契約容量変更のお願い」
＞と、いうものでした。

ををっ、ついに来ましたか(^^;;;;

# 何が「ついに」なのか分からないひとは過去記事参照(^^;;

＞で、正確な容量はFTPですべてのファイルのバイト数をチェックし
＞て合計して下さいと・・。ちょっと非現実的では(^^;)

うーん、

    #!/bin/sh
    
    echo "Content-Type: text/plain"
    echo ""
    du -sk /my/home/directory 2>&1

とかやるのがいちばん現実的ですかねぇ。
ファイルが多いと時間かかるし、CGIから読めない
ディレクトリが計算に含まれないという欠点も
あるのですが。


ふつうは、やっぱり

・S号機みたいにsuidな(ユーザ権限で動く)CGIを
  導入する

・容量チェックのページだけでもduか何かで計算
  してあげる

・無理矢理quotaシステムを改造して容量計算の
  方法を変える:-)

とかだと思うんですけど…＞BIGLOBE

# …はっ、ということは、にあさんのところにもメールが…(^^;;

フォロー記事投稿

記事のキャンセル

Yasu.Fさん、こんばんは！

2月18日に、Yasu.Fさんは書きました。

＞# 何が「ついに」なのか分からないひとは過去記事参照(^^;;

なーんだ、もうすでに知っている人は知っていたんですねっ。

＞うーん、
＞
＞    #!/bin/sh
＞    
＞    echo "Content-Type: text/plain"
＞    echo ""
＞    du -sk /my/home/directory 2>&1
＞
＞とかやるのがいちばん現実的ですかねぇ。

-skはダメだったんですが、とりあえずduで調べたところ、
６ＭＢくらいでした。（そのうち会議室は3300KB）
ちなみにうちの会議室の総記事数は約1300です。
うーむ、放っておいたら削除されるのだろうか(^^;)

＞# …はっ、ということは、にあさんのところにもメールが…(^^;;

どうなんでしょう。この日を予測してすでに増設してあったりして。

フォロー記事投稿

記事のキャンセル

2月18日に、NKさんは書きました。

＞-skはダメだったんですが、とりあえずduで調べたところ、
＞６ＭＢくらいでした。（そのうち会議室は3300KB）
＞
うちは各ディレクトリのパーミッションを必要最小限しか与えてないので、
サーヴァ権限でduかけても全然計れないので、今まで手元のバックアップ
ディレクトリにduした値から推測していたのですが、今回無理矢理ユーザ
権限で自分のホームディレクトリ以下全てにduをかける機構を書いて実行
してみたら、軽く16MB超えてました。(汗)
＃ 10MB超えてるのは分かってたのだけど...

＞＞# …はっ、ということは、にあさんのところにもメールが…(^^;;
＞どうなんでしょう。この日を予測してすでに増設してあったりして。
＞
ご丁寧に3通も来てました。(爆)

取りあえず、次版でDBM使うため余計に容量食うようになるのと、ファイル数
制限の方に引っかかるとヤなので最大増設の25MBにしておきましたが、それでも
全文検索機能を入れる余裕は無くなってしまったなぁ (^^;;

早めにアーカイヴ会議室を導入して容量圧縮を図るか、サーヴァ移転/並列稼動を
考えねばならないようですね。

＃ 将来の移転先として狙いを付けている所は有るんですが、去年の終わり頃に
＃ 分かるはずだった増強計画がいまだに発表されてないので、チョット様子見に
＃ なっています。(^^;;

フォロー記事投稿

記事のキャンセル

2月18日に、Yasu.Fさんは書きました。

＞ふつうは、やっぱり
＞
＞・S号機みたいにsuidな(ユーザ権限で動く)CGIを
＞  導入する
＞
今回の変更がsuid機構の導入に伴う物なら良いのですが...

＞・容量チェックのページだけでもduか何かで計算
＞  してあげる
＞
単に、これを作ったのだけど、容量制限と容量表示を一緒に行なうので
事前に容量表示機構だけの先行導入が出来ない、とか言う落ちでは無いかと
邪推しています。(^^)

いづれにせよ、来たメールには「ディスク容量の算出方法を改善し、より厳密に
容量の制限をさせていただく」としか書いてないので、duを使う物なのかどうかは
良く分からないですね。
＃ 自分で算出する場合はファイルサイズを合計せよ、って書いて有るけど、
＃ 本当にそう言う厳密な算出法なのかしらん。だったらずいぶんduの結果よりは
＃ サイズ減るけど、計算にやたら時間かかりそう。(汗)

一応、サポートに質問のメールを出しておいたけど、返事が返ってくるのは
いつかしら...

フォロー記事投稿

記事のキャンセル

2月18日に、にあは書きました。

＞いづれにせよ、来たメールには「ディスク容量の算出方法を改善し、より厳密に
＞容量の制限をさせていただく」としか書いてないので、duを使う物なのかどうかは
＞良く分からないですね。
＞＃ 自分で算出する場合はファイルサイズを合計せよ、って書いて有るけど、
＞
思いの外早くサポートから返事がきて、ファイルサイズを合計せよ、と書いたのは
ユーザが簡単に出来る方法を示唆しただけであって、実際にはブロックサイズを
考慮した計算をしなくてはならない、と言うことで、結局、duの出力を使っている
様な感じでした。はっきりとは書いてないけど。

＃ ただ、あたしの使用容量は2月10日の時点で14568KBだったそうですが、
＃ 昨日の時点でduかけたら、16579KBだったので、チョット誤差が大きいな。
＃ 単純にduの結果使っているんじゃ無いのかな?

そのうち、システムの容量表示も正しい値を表示するようになるそうです。(そりゃそうだ)

フォロー記事投稿

記事のキャンセル

FAQ Projectでも発動させようかなぁ、と思わないこともない
今日この頃…(笑)

以上7記事（キャンセル分を含む）

ホームペーヂに戻る