新緑も芽生え始めてきたリバーサイド公園を自転車で2018年04月24日 12時19分50秒

新緑も芽生え始めてきたリバーサイド公園を自転車で。ここ、数日で大分木の芽も芽吹いてきた。桜も六、七歩咲きになり、新芽を広げ始める木々も増えて、茶色かった道のりが緑とピンクで鮮やかになり始めた。

一週間前と比べても雰囲気が一目で分かる程変わっている。 一週間前のリバーサイド公園。はまだ緑色があまりない。

二十分。

娘が初めて友達の家にお泊まり2018年04月23日 12時23分52秒

八歳の娘が友達の家でお泊まりをしてきた。

以前から日本語学校で仲良くしている、友達に誘われて。何度か声をかけてもらっていたのだが、運悪くお互いの都合が合わないことが続いていた。今回、やっとの事でお互いの都合がついた。

学校が終ってから、そのまま一緒に引き取って貰いそのまま遊びに行った。その為、娘に会ったのは次の日の日曜日。迎えに行ったら、帰る準備は終っていて、駄々もこねずにしっかりと、さようならをしてきた。娘はご機嫌で帰って来て楽しかったと報告。

一週間前に、お泊まりが決まったと伝えたらすぐに自分の着替えなどの準備を始めた。今週は現地校が一週間の春休み。そのため前日から、自分でチーズケーキを焼いて準備をした。御友達のお宅でみんなで美味しく食べてもらったようだ。

ハドソン川沿いも桜が咲き始めた2018年04月22日 12時07分28秒

ハドソン川沿いも桜が咲き始めた。ニューヨーク、マンハッタンの西側を流れるハドソン川。ここにもやっと春の訪れを感じられる様になってきた。やっと、桜の木々が花を開き始めた。その道を自転車で。

十分。

やっと桜も咲き始め春の訪れを感じられるセントラルパーク2018年04月20日 21時01分02秒

やっと桜も咲き始め春の訪れを感じられるセントラルパーク。やっとセントラルパークの咲き始めた。今年は二週間くらい遅れていると思う。セントラルパークの南端から北端まで東側の周回道路を自転車で北上する。

所々に桜をまとめて植えてあるところがあって、その辺りはピンクと白に染まっている。また、他にも黄色い花を付けている木や根本のチューリップなども咲き始めた。

と比べてもだいぶ花が咲き始めたり、木々の新緑が始まり、様子が変わっているのが分かる。

十三分四十秒。

リバーサイド公園の桜が咲き始めた2018年04月19日 13時31分23秒

リバーサイド公園の桜が咲き始めた。今年は、寒さのため桜の開花が遅れている。やっとちらほらとハドソン川沿いの桜が咲き始めた。

暖かくなり始めたため、チラホラとジョギングや散歩をする人達が増え始めた。なお、春先には公園の木の枝を切り落としたり、舗装や設備の修理などが行われる様で、今回も一部が工事中。

二十一分。

git clone --depth 1 で最新の履歴だけを取得2018年04月13日 12時13分18秒

git clone --depth 1 で一部のみの取得が可能。コミット数が多いときにディスクとファイルの転送を削減できるので便利。

マンハッタンの 7th アベニューを自転車で北上2018年04月12日 20時42分57秒

マンハッタンの 7th アベニューを自転車で北上。セントラルパークの南端から開始。セントラルパークを抜けた後はそのまま、7th アベニューを北上。マンハッタンの終りに差し掛かり 145 番街で左折。その後はセント・ニコラス・アベニューからセント・ニコラス・プレイスを北上。171 番街を通ってジョージワシントン橋まで向かう。

今年は寒い日が続き、既に四月の二週目だと言うのにまだセントラルパークの木々もまだ蕾のままが多い。やっと少し花が開き始めた。

三十八分。

セントラルパークの春の訪れを撮り直し2018年04月10日 21時07分22秒

セントラルパークの春の訪れを撮り直し。前回は完全にピントがずれて曇り画像。先日の撮影ではピントが合わず、セントラルパークの撮影に失敗したので撮り直し。ちらほら、白、黄色、ピンクの花が咲きは始める木が目につくようになってきた。

公園を抜けた後は、セント・ニコラス・アベニューに入り、そのまま直進して、セント・ニコラス・プレイスを抜けて、エッジコームアベニューを抜ける。車の通りが、セント・ニコラス・アベニューよりも少なくて、裏道を抜ける感じで走りやすい。

三十八分。

ハドソンテラスから崖の急斜面をハドソン川まで一気に翔け下りる2018年04月09日 17時02分00秒

ハドソンテラスから崖の急斜面をハドソン川まで一気に翔け下りる。まず、ハドソンテラスを北上。これはジョージワシントン橋のたもとを通る道。そして、祖の突き当たりを右折。この辺りの地名は別名イングルウッドクリフス。クリフは崖の意味。ハドソン川のわきを急な崖がそびえ立っている。その斜面を一気に川岸まで一気に急降下。

道は痛んでいて凸凹。振動でカメラが外れた。

最近、八歳の娘が自転車が気に入っている。小学生に入った頃に練習をして、乗れるようにはなっていた。三週間程前に、友達の家に遊びに行った時に、自転車で遊んだそうだ。それ以来、大のお気に入り。二週間続けて、近くの公園に自転車に乗りに出かけた。

結構頑張って乗るので、公園を周回するのではなく、ある程度のコースと考えてニューヨークを一望出来るこの公園へ。子供達は車に自転車を積んで行った。

川沿いコースを走り出すと思ったよりも勾配がある。一度、諦めて引き返して休憩した。休憩後の再挑戦は、しっかりと坂を登りきり、結構遠くまで行った。ジョージワシントン橋の近くまで来て、下に Ross Dock Picnic Area が見えるまで。全部で 10 キロメートルぐらいは走ったようだ。

七分。

zfs send は破損したファイルがあると使えない2018年04月08日 23時36分06秒

ハードディスクが故障し、新しいディスクが届いたので、復旧作業をしている。

念のためにバックアップを確認してから進めている。他から手に入れたファイルや、既にバックアップとして保存されていたファイルは、別には保持していなかった。その様な優先度の低いファイルも再取得の手間を減らすために、再バックアップを進めている。

その中で、zfs send でうまく行かないファイルシステムがあった。

$ zfs list -r -t all scratch/media
NAME                   USED  AVAIL  REFER  MOUNTPOINT
scratch/media          281G  1.04T   280G  /mnt/zfs/media
scratch/media@2016     407K      -   143G  -
scratch/media@2017     150M      -   270G  -
scratch/media@2018     279K      -   279G  -
$ zfs send -v scratch/media@2016 > /dev/null
full send of scratch/media@2016 estimated size is 144G
total estimated size is 144G
TIME        SENT   SNAPSHOT
14:25:42   70.2K   scratch/media@2016
14:25:43   25.8M   scratch/media@2016
14:25:44   58.5M   scratch/media@2016
14:25:45   62.1M   scratch/media@2016
...
14:26:32   1.44G   scratch/media@2016
14:26:33   1.46G   scratch/media@2016
14:26:34   1.48G   scratch/media@2016
14:26:35   1.50G   scratch/media@2016
warning: cannot send 'scratch/media@2016': Input/output error
途中で止まっている。気がかりは数日前には既にあった。zpool で確認すると、このスナップショットには壊れたファイルがある。
$ zpool status -v
  pool: scratch
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilvered 465G in 36h43m with 112 errors on Sat Apr  7 12:37:58 2018
config:

        NAME                                    STATE     READ WRITE CKSUM
        zfs                                     DEGRADED     1     0   453
          raidz1-0                              DEGRADED     1     0 1.62K
            gpt/zfs1                            ONLINE       0     0     0
            gpt/zfs2                            ONLINE       2     0     0  (resilvering)
ering)
            gpt/zfs3                            ONLINE       1     0     0  (resilvering)
            15470053991832379715                UNAVAIL      0     0     0  was
/dev/gpt/zfs4

errors: Permanent errors have been detected in the following files:

        scratch/media@2017:/freebsd/FreeBSD-10.2-RELEASE-i386-disc1.iso
        /mnt/scratch/media/freebsd/FreeBSD-11.1-RELEASE-i386-disc1.iso
        <0x202>:<0x2a>
        <0x2a>:<0x3f>
        <0x2a>:<0x49>
        <0x2a>:<0x57>

特に復旧できなくても大きな問題ではないので、rsync でファイルをコピーした。

実は、これ以外にも壊れていたファイルがあって、こまめにスナップショットを取っていたファイルシステムは難を逃れることが出来た。zfs スナップショットはある程度こまめに、そして各スナップショットのサイズを考慮して保持しておいた方が、復旧に楽だ。

上の例では、scratch/media の FreeBSD 11.1 RELEASE の ISO ファイルは壊れていた。また、media@2017 のスナップショットも壊れている。ただ、media@2017 は他の場所に既に、zfs send のバックアップが保存されていた。そのため、FreeBSD-11.1-RELEASE-i386-disc1.iso のファイルを消し、media@2018_04 のスナップショットを取った。

$ zfs send -i 2017 scratch/media@2018_04
幸いにも、この差分には壊れたファイルは存在しない。FreeBSD-10.2-RELEASE-i386-disc1.iso はスナップショット上では壊れているが、送られる必要が無いからだ。

これを契機に、zfs スナップショットは 50GB ぐらい毎に保持する事にした。こうすることで、ファイルが破損しても zfs send で送れるスナップショットが残る可能性があがる。また、一つのスナップショットが大きくなると、転送に時間が掛かるのも一つの理由だ。