QuicksearchDisclaimerThe individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.
Navigation |
No, ZFS still doesn't need a fsck. Really!Sunday, March 31. 2013Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
... but ZFS does need a defragmentation tool
![]()
#1
on
2013-03-31 18:47
is bp_rewrite cancelled or will it appear in ZFS for Solaris12?
#1.1
on
2013-03-31 19:44
Yes, i feed up doing zfs send | zfs receive to defragment (offline) the zpool
#1.2
on
2013-04-01 03:06
"The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair"
Douglas Adams
#2
on
2013-03-31 19:47
You should mention, though, that ZFS at least has the scrub and resilver command sets which at least in part do what fsck does for other FSs... (and if that job is only to verify the integrity and give the admin a warm fuzzy feeling...)
#3
on
2013-04-01 00:17
ZFS scrubs compute checksums and compare them with result stored on-disk. As most other filesystems doesn't have those checksums with their data, it can't be a part of their checksums. The same is resilvering.
I absolutely love ZFS. I've been using it on my home server to safeguard family photos and videos, etc. for years (since OpenSolaris). I use it at work extensively (Solaris 11.1 zone/zfs integration is incredible).
That said, it does lack one critical tool for all, but those who can afford an enterprise backup solution: a zfsdump/zfsrestore utility. So I've got the most advanced filesystem/volume-management-system/etc. ever released, and I'm using the most ancient software to back it up. I'm using tar for backups, since I can't use zfs send (which I'd actually prefer) due to the fact that my tapes are LTO3 and can only hold 400GB each, while my data is massively larger than that. The zfs send command (for those who don't know) is not capable of handling "end of tape", so it won't prompt you to change tapes, it just dies with an error when it gets there. The only way I could use zfs send would be if I were to create many separate zfs filesystems, artificially separating the pictures and videos into groups under 400GB each (which would break the way I have them organized). I'm amazed it still lacks this feature - as when I search I find postings with people begging for it going back to 2005! Also: Love the blog - glad you're still doing it after all these years. ![]()
#4
on
2013-04-02 01:53
Stop Using Tapes.
![]() There are two correct ways to back up a zpool: 1. rsync the contents to a separate pool, on separate hardware, preferably in a geographically separate facility. take a snapshot on the remote zpool after each rsync job ends. 2. take frequent snapshots (I prefer hourly). zfs send -RI | zfs receive to a separate pool, on separate hardware, preferably in a geographically separate facility. you don't need to worry about taking snapshots on your remote pool, because your remote pool will have all the snapshots your local pool does. There are pros and cons to each approach. The big pro for zfs send | zfs receive is that it's RIDICULOUSLY more efficient for large datasets, as it doesn't need to stat files or tokenize data before squirting the delta over the network. The big pro for rsync is that potential bugs in the underlying filesystem can't be transmitted by rsync, whereas they potentially could with zfs send | zfs receive since you're actually moving metadata, not just data. IME it's actually cheaper to back up to hard drives than it is to tapes anyway. Short life span and everything else wrong with tapes just makes them a complete lose IMO. The author does not allow comments to this entry
|
The LKSF bookThe book with the consolidated Less known Solaris Tutorials is available for download here
Web 2.0Contact
Networking xing.com My photos Comments
about Mon, 01.05.2017 11:21
Thank you for many interesting
blog posts. Good luck with al
l new endeavours!
about Fri, 28.04.2017 13:47
At least with ZFS this isn't c
orrect. A rmdir for example do
esn't trigger a zil_commit, as
long as you don't speci [...]
about Thu, 27.04.2017 22:31
You say:
"The following dat
a modifying procedures are syn
chronous: WRITE (with stable f
lag set to FILE_SYNC), C [...]
|