標籤彙整: fsck

Fix a not clean, unmountable disk on FreeBSD

發佈日期: 作者:
回覆

“fsck is our good friends” – By an accident poweroff, the mounted hard disk was not unmounted yet, and the power supply just been cut off … from the next boot, FreeBSD booted into single user mode because the system couldn’t mount my harddisk properly, let’s talk about how to fix it.

In single user mode, I just comment the line to mount the partition on my hard disk in /etc/fstab and then reboot, let my system boot normally first (the system was installed on another disk, if you have only one disk, it’s another situation), and try to mount the partition manually :

$ sudo mount /dev/ada1p1  /mnt/hdd

mount: /dev/ada1p1: R/W mount of /mnt/hdd denied. Filesystem is not clean – run fsck.: Operation not permitted

Still not work, so I use fsck_ufs to check the partition (it’s a UFS filesystem), and see if we can repair it:

$ sudo fsck_ufs /dev/adap1

** /dev/ada1p1
** Last mounted on /mnt/hdd
** Phase 1 – Check Blocks and Sizes
** Phase 2 – Check Pathnames
** Phase 3 – Check Connectivity
** Phase 4 – Check Reference Counts
** Phase 5 – Check Cyl groups
2005994 files, 8009350 used, 143322246 free (29606 frags, 17911580 blocks, 0.0% fragmentation)

***** FILE SYSTEM MARKED CLEAN ****

Looks great, it took me about only 3 minutes and didn’t report any bad news, for different situation, you may got different result, like additional message: ** Phase 1b – Rescan for more Dups, it depends.

Now we can try to mount it again:

$ sudo mount /dev/ada1p1  /mnt/hdd

No error message, awesome, let’s make sure it’s mounted:

$ df | grep ada1p1
/dev/ada1p1    ufs    577G    33G    498G    6%    /mnt/hdd

The end.

Convert ext3 to ext4 filesystem on Debian Wheezy

發佈日期: 作者:
回覆

老調重彈了，最近又再做這件事是因為Proxmox VE預設是用ext3當作檔案系統，某一台機器因為有點問題，灌Proxmox的時候一開始沒打算要當正式系統，也就沒特別改設定，但灌好後因為懶了 … 就直接上線了 … 偶然發現這個問題，順便重新作一下筆記怎麼樣轉到ext4，轉到ext4的好處以及效能差異就不用多說了，幾乎是完剩ext2、ext3，好檔案系統，不轉嗎?

如果懶的話，最簡單的方法就是去改fstab，直接把ext3掛成ext4，效能就可以有所提升，但只能使用到那些不需要修改到檔案系統的功能，並且可以重新用ext3的方式掛載，而要有比較完整的轉換則要做以下動作:

  1. 把要做轉換的分區umount(如果是root filesystem就進single user mode或用其他系統開機吧)，DEV自行替換成對應代號
    # umount /dev/DEV

  2. 先做一次fsck
    # e2fsck -fyv /dev/DEV

  3. 沒問題的話就可以把ext4的功能打開了，這邊要注意 … 這是不可逆的操作，並且要和下個動作連貫完成
    # tune2fs -O extents,uninit_bg,dir_index /dev/DEV

  4. 調整完後要修一下(這邊會看到找到錯誤是正常現象)
    # e2fsck -fyvDC0 /dev/DEV

  5. 調整fstab的掛載格式
    -> 自己去fstab理面把該分區的ext3改成ext4吧!

  6. 重組
    # e4defrag -c -v /dev/DEV
    -> ext4開始使用extents來取代傳統的block mapping，在對大檔案操作時能有顯著的效能提升，而這部份是在剛剛的轉換沒有做的(tuen2fs只有把feature打開而以)，轉換完成後新增的檔案自然是都會使用到這樣的功能，但原先已經存在於filesystem上的檔案必須要到下次被寫入時才會以新的方式寫入，但系統上有不少檔案是久久才會寫一次但可能經常要被讀取的，在被重新寫入以前便無法享受到這樣的效能改善，所以這邊透過e4defrag來幫我們做這件事!

過程中如果有出現錯誤的話就先解掉再往下一步走，像fsck這種工作做完一次還可以做第二次確保都沒問題了再往下走，過程並不複雜，剛好也可以順便檢查檔案系統有沒有問題，比較麻煩的大概就是root filesystem因為要unmount所以系統必須停機，但換來的效能是值得的!

(我之前硬碟壞掉就會出現fsck永遠修不完的現象，每次抓到的錯誤都不一樣，修完一次下次還是有得修，那很明顯是硬碟壞了)

Error: Read-only file system on Linux

發佈日期: 作者:
回覆

Today I found that there is a strange situation, in certain mount point on my web server (Debian GNU/Linux 7.8), every process with write behavior will get messages like this (That’s the result from command touch test):

touch: cannot touch `test’: Read-only file system

I don’t think I mount it as read-only, so I check it with(the mount point is /srv):

$ mount | grep srv

And I got:

/dev/sdb1 on /srv type ext4 (ro,relatime,data=ordered)

Very strange … there was something wrong, could I remount it with r/w? I tried:

$ sudo mount -o remount,rw,relatime,data=ordered /srv

Hmmmm …

mount: cannot remount block device /dev/sdb1 read-write, is write-protected

Okay, seems I need to check the filesystem …

$ sudo umount /srv
$ sudo fsck.ext4 /dev/sdb1

The process didn’t take a very long time, just within few mins, and that’s the result:

e2fsck 1.42.5 (29-Jul-2012)
/dev/sdb1: recovering journal
/dev/sdb1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdb1: 796453/122077184 files (3.8% non-contiguous), 321192367/488281498 blocks

Let’s mount it again:

$ sudo mount -o rw,relatime,data=ordered /srv

Oh, I didn’t get any error message this time, let’s check it again:

$ mount | grep srv

And … it’s good again

/dev/sdb1 on /srv type ext4 (rw,relatime,data=ordered)

Okay, nice … it’s very easy this time, I’ve got some disks with damaged partition before, event I can’t not recognize its partition type, though I fixed it, but I didn’t record the process that time, haha.