[HN Gopher] ntfs2btrfs: In-place conversion of NTFS filesystem t...
___________________________________________________________________
ntfs2btrfs: In-place conversion of NTFS filesystem to Btrfs
Author : andrew-ld
Score : 143 points
Date : 2022-03-07 15:11 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| boricj wrote:
| From the same person that made WinBtrfs and Quibble, a Windows NT
| Btrfs installable filesystem and bootloader. And yes, with all of
| that one can boot and run Windows natively on Btrfs, at least in
| theory.
| danudey wrote:
| Can you share a btrfs pool between Windows and Linux? That
| would be a game-changer.
| sitkack wrote:
| You mean like so Windows can ruin your Linux? Why trust
| hardware isolation when software will do!
| basilgohar wrote:
| I used to be in the "why BTRFS" camp and religiously would only
| install ext4 without LVM on Fedora for my laptops, desktops, and
| servers. When I saw so many subsequent releases persist in
| offering BTRFS by default, I decided to try it for a recent
| laptop install, because honestly, the appeal of deduplication,
| checksumming, snapshotting, and so many other features that
| modern FSes generally come with (e.g., ZFS), I just decided to
| jump the gun and went ahead and installed it.
|
| I can safely say it has not presented any problem with me thus
| far, and I am at the stage of my life where I realize that I
| don't have the time to fiddle as much with settings. If the
| distributions are willing to take that maintenance on their
| shoulders, I'm willing to trust them and deal with the
| consequences - at least I know I'm not alone.
| stjohnswarts wrote:
| I was an early adopter and some bad experiences early on made
| it a bitter pill. I swore it off for a decade, and about year
| and half came back around. It's MUCH MUCH better now. With
| automated "sensible" settings for btrfsmaintenance tools it's
| actually just fine now.
| badsectoracula wrote:
| > deduplication, checksumming, snapshotting, and so many other
| features that modern FSes generally come with (e.g., ZFS)
|
| Does any other FS on Linux provide those?
| coder543 wrote:
| bcachefs is probably the other big name here, but since
| distros still seem to pick btrfs, I don't think it's
| considered "production ready" yet. The bcachefs website still
| labels it as "beta" quality.
| doublepg23 wrote:
| The best way to stay up-to-date on bcachefs is the Patreon,
| Kent writes great updates there.
|
| https://www.patreon.com/bcachefs
| assbuttbuttass wrote:
| bcachefs isn't even mainlined yet. You'd have to build your
| own kernel to test it out (or I think NixOS packages it)
| londons_explore wrote:
| bcachefs is written by the same person who wrote bcache...
| And that has a lot of subtle eat-your-data pitfalls.[1] I
| don't really trust bcachefs not to do the same.
|
| [1]: https://omattos.com/2020/01/02/bcache.html
| deknos wrote:
| i also wonder, if there are parts of features of zfs/btrfs in
| other parts of fs systems... someone should build a
| comparison matrix :D
| LeoPanthera wrote:
| VDO provides a compression and duplication layer for any
| traditional filesystem.
|
| https://www.redhat.com/en/blog/look-vdo-new-linux-
| compressio...
| cmurf wrote:
| VDO isn't in the mainline kernel still.
| throwawaylinux wrote:
| That's traditionally the domain of logical volume managers.
| coder543 wrote:
| Snapshots, sure.
|
| But... any of the other stuff? Checksums, deduplication,
| compression, etc. Citations, please.
|
| LVM VDO wasn't really a thing until a couple of years ago,
| and I've never actually heard anyone recommend using it.
| Definitely not within its "traditional domain".
|
| Perhaps you mean on other operating systems... when this
| discussion is all about a Linux filesystem and whether
| other Linux filesystems provided these features, including
| the comment you replied to?
| throwawaylinux wrote:
| > But... any of the other stuff? Checksums,
| deduplication, compression, etc. Citations, please.
|
| Yes. The Linux LVM logical volume manager for example can
| do those things.
|
| Traditional domain meaning this kind of data management
| traditionally came under the purview of LVMs. Not that an
| implementation has had particular features for a length
| of time, but that you might (also) look there rather than
| the filesystem for those features.
| dotancohen wrote:
| Are you using a UPS on the desktop? A recent HN thread
| highlighted BTRFS issues, especially with regards to dataloss
| on power loss. Also, there's a "write hole issue" on some RAID
| configurations, RAID 4 or 6 I think.
|
| That said, I'm thinking about leaving a BTRFS partition
| unmounted and mounting it only to perform backups, taking
| advantage of the snapshotting features.
| amelius wrote:
| Are they testing BTRFS with power interruptions (or simulated
| equivalents thereof?)
| waffleiron wrote:
| It's RAID 5/6, there is a great status page:
|
| https://btrfs.wiki.kernel.org/index.php/Status
| michaelmrose wrote:
| This would seem to suggest that ANY raid configuration is
| unacceptable.
|
| Device replace
|
| --------------
|
| >Device replace and device delete insist on being able to
| read or reconstruct all data. If any read fails due to an IO
| error, the delete/replace operation is aborted and the
| administrator must remove or replace the damaged data before
| trying again.
|
| Device replace isn't something where "mostly ok" is a good
| enough status.
| pkulak wrote:
| It's obviously not there as a NAS filesystem, ZFS drop-in
| replacement, etc. But if what you take away from that is that
| BTRFS is no good as a filesystem on a single drive system,
| you're missing out. Just a few weeks ago I used a snapshot to
| get myself out of some horrible rebase issue that lost half my
| changes. Could I have gone to the reflog and done other magic?
| Probably. But browsing my .snapshots directory was infinitely
| easier!
| ahartmetz wrote:
| By the way, "git reflog" can usually get you out of horribly
| botched rebases without using special filesystem features:
| git reset --hard <sha1 of last good state from reflog>
| vlovich123 wrote:
| The reflog can be a PITA to walk through. A less well known
| thing is that you can spelunk through the reflog by saying
| `<ref>@{N}` which means whatever commit `<ref>` was
| pointing at N changes to the ref ago. Super handy to
| double-check that the rebase squashing commits didn't screw
| things up if there were merge conflicts in the fixups.
| bb88 wrote:
| You can typically make a branch and push it up to the server,
| and I usually do this before any rebase. In future
| development scenarios (mac, windows) will you be able to do
| this reliably in the future?
| oauea wrote:
| Or just write down the commit hash. Or just learn your
| tools and stop worrying because git reflog got you covered.
| bb88 wrote:
| I've had issues with reflog that were not easily solved
| in the past, and wasn't clear what the fix was.
|
| Also tagging is better than writing it down. Like
| initials+date.
| azinman2 wrote:
| Synology ships it for their NAS
| doublepg23 wrote:
| Sort of. They use it on top of dm-raid and use dm-integrity
| for the checksum features. They claim BTRFS RAID is
| unstable.
|
| https://kb.synology.com/en-
| us/DSM/tutorial/What_was_the_RAID...
| blibble wrote:
| > They claim BTRFS RAID is unstable.
|
| and they'd be correct
| vetinari wrote:
| Synology is running on top of mdraid, but does not use
| dm-integrity. Since it can be enabled per-share, and
| share creates a btrfs subvolume, that would be kind of
| difficult.
|
| For scrubbing, plain-old btrfs-scrub is being used.
| ziml77 wrote:
| Does BTRFS actually need to be augmented like that? I've
| been afraid of using it for a NAS because it doesn't
| sound like it's as trustworthy as ZFS when it comes to
| handling bitrot. But I don't know if that's actually
| true. When I tried to find info on it a couple weeks ago,
| a lot of people were trying to claim that bitrot isn't a
| thing if you have ECC RAM.
| kevin_thibedeau wrote:
| ECC can't protect the interface to your storage device.
| Bit flips can happen at any point in that chain.
| StillBored wrote:
| Which part of the chain isn't protected by at least a
| packet CRC?
|
| I think the answer is its all covered.
| michaelmrose wrote:
| It's raid 5/6 comes with a warning from the developers
| not to use it and RAID 1 is a weird arrangement that
| actually keeps 2 copies on however many disks and can
| lose data if a disk comes and goes for example with a bad
| cable.
|
| Bitrot still happens with ECC.
| StillBored wrote:
| Bitrot is a thing, getting random bit flips/etc past all
| the ECC and data integrity checks in the storage path is
| much harder.
|
| Having filesystem level protection is good, but it its
| like going from 80% to 85% protected. That is because the
| most critical part remaining unprotected in a traditional
| RAID/etc system is actually the application to filesystem
| interface. Posix and linux are largly to blame here
| because the default IO model should be async interface
| where the completion only fires when the data is
| persisted and things like read()/write()/close() should
| be fully serialized with the persistence layer.
| Otherwise, even with btrfs the easiest way to lose data
| is simply write it to disk, close the file, and pull the
| power plug.
| chasil wrote:
| BtrFS was previously restricted to crc32c checksums. This
| was enhanced to allow several more, including sha256. The
| crc32c checksum has also been improved as xxhash, which
| promises fewer collisions for safer deduplication. When
| configured for sha256, BtrFS uses a checksum that is as
| strong as ZFS.
|
| However, the checksum must be chosen at the time of
| filesystem creation. I don't know of any way to upgrade
| an existing BtrFS filesystem.
|
| Contrast this to ZFS, which allows the checksum to be
| modified on a file-by-file basis.
| LinuxBender wrote:
| _But browsing my .snapshots directory was infinitely easier!_
|
| I second this however I don't use the filesystem to get this
| functionality. I most often use XFS and have a cronjob that
| calls an old perl script called "rsnapshot" [1] that makes
| use of hardlinks to deal with duplicate content and save
| space. One can create both local and remote snapshots.
| Similar to your situation I have used this to fix corrupted
| git repos which I could have done within git itself but
| rsnapshot was many times easier and I am lazy.
|
| [1] - https://wiki.archlinux.org/title/rsnapshot
| amelius wrote:
| Let me guess: you use XFS because of the large number of
| hardlinks it allows out of the box (as opposed to the small
| number allowed by ext4)?
| chris37879 wrote:
| Snapshots are the best thing in the world for me on Arch. I'm
| specifically using it cause I like to tinker with exotic
| hardware and it has the most sane defaults for most of the
| things I care about. Pacman is great, but the AUR can be a
| bit a sketchy sometimes on choices that package authors make.
| Having snapshots every time package changes happen that I can
| roll back to from my boot loader is _awesome_. If you've ever
| used a distro that does kernel backups in your boot loader,
| it's like that, except it's whole packages at a time! And
| being able to use subvolumes to control which parts of a
| snapshot to restore is awesome. I can roll back my system
| without touching my home directory, even on a single drive
| setup!
| Teknoman117 wrote:
| Incremental snapshots as a backup tool and being able to
| chroot into a new snapshot of root to do updates is so
| useful.
| 0xbadcafebee wrote:
| > If the distributions are willing to take that maintenance on
| their shoulders, I'm willing to trust them and deal with the
| consequences - at least I know I'm not alone.
|
| But then they make changes that add an insane amount of
| complexity, and suddenly you're running into random errors and
| googling all the time to try to find the magical fixes to all
| the problems you didn't have before.
| regularfry wrote:
| It certainly used to be the case that BTRFS had some nasty
| behaviour patterns when it started to run low on space. It
| could well be that it has not presented any problem for you
| _yet_.
|
| On the other hand, those days might be behind it. I haven't
| kept track.
| cmurf wrote:
| There are still edge cases but I can count on one hand the
| number of users who have run into it since Fedora switched to
| Btrfs by default (on desktops) two years ago (and Cloud
| edition in the most recent Fedora release late last year).
|
| The upstream maintainer of btrfs-progs also maintains btrfs
| maintenance https://github.com/kdave/btrfsmaintenance which
| is a set of scripts for doing various tasks, one of which is
| a periodic filtered balance focusing on data block groups. I
| don't run it myself, because well (a) I haven't run into such
| a bug in years myself (b) I want to run into such a bug so I
| can report it and get it fixed. The maintenance script
| basically papers over any remaining issues, for those folks
| who are more interested in avoiding issues than bug reporting
| (a completely reasonable position).
|
| There's been a metric ton of work on ENOSPC bugs over the
| years, but a large pile were set free with the ticketed
| ENOSPC system quite a few years ago now (circa 2015? 2016?)
| alerighi wrote:
| BTRFS works fine. I use it on my everyday laptop without
| problems. Compression can help on devices with not a lot of
| disk, and also copy on write. However, BTRFS has its drawbacks,
| for example it's tricky to have a swapfile on it (now it's
| possible with some special attributes).
|
| Also I wouldn't trust BTRFS for the purpose of data archiving,
| for the fact that ext4 is a proven (and simpler) filesystem,
| thus it's less likely to became corrupt, and it's more likely
| to being able to recover data from it if it will become corrupt
| (or the disk has some bad sectors and that sort of stuff).
| chris37879 wrote:
| I didn't know about the swapfile thing... but TIL. I had been
| wondering how to to make a non-snapshotted volume for some
| other reasons, though, so that's a 2 birds with one stone
| thing, thank you!
| vetinari wrote:
| > Also I wouldn't trust BTRFS for the purpose of data
| archiving, for the fact that ext4 is a proven (and simpler)
| filesystem, thus it's less likely to became corrupt, and it's
| more likely to being able to recover data from it if it will
| become corrupt (or the disk has some bad sectors and that
| sort of stuff).
|
| On the contrary; I'm using btrfs and not ext4 on NAS
| (Synology) specifically, because the former does checksumming
| and bitrot detection and the latter does not.
| rinron wrote:
| I was using urbackup with ext4 and was having issues that
| caused corruption and couldn't figure out why, seen a
| recommendation to use urbackup with BTRFS and have had no
| corruption since. I have used ext4 in every other use case
| and had no issue so im not saying ext4 is at fault but so
| far BTRFS has worked great for me.
| nine_k wrote:
| With this, I wonder why ext4 and not XFS.
| cmurf wrote:
| I'm not sure how you prove that ext4 is less likely to become
| corrupt. But it is easily shown that it's less likely to
| inform you that there's corruption.
|
| Quite a lot of the assumptions of earlier file systems is the
| hardware either returns correctness, or reports a problem
| e.g. uncorrectable read error or media error. That's been
| shown to be untrue even with enterprise class hardware,
| largely by the ZFS developers, hence why it exists. And also
| why ZFS has had quite a lot less "bad press" where Btrfs
| wasn't developed in a kind of skunkworks, it was developed
| out in the open where quite a lot of early users were using
| it with ordinary every day hardware.
|
| And as it turns out, we see most hardware by make/model doing
| mostly the right things, a small number of make/models,
| making up a significant minority of usage volume, don't do
| the right things. Hence, Btrfs has always had full
| checksumming of data and metadata. Both XFS and ext4 were
| running into the same kinds of problems Btrfs (and ZFS before
| it) revealed - torn writes, misdirected writes, bit rot,
| memory bit flips, and even SSD's exhibit prefail behavior by
| returning either zeros or garbage instead of data (or
| metadata). XFS and ext4 subsequently added metadata
| checksums, which further reinforced the understanding that
| devices sometimes do the wrong thing and also lie about it.
|
| It is true that overwriting filesystems have a better chance
| of repairing metadata inconsistencies. A big reason why is
| locality. They have fixed locations on disk for different
| kinds of metadata, thus a lot of correct assumptions can be
| made about what should be in that location. Btrfs doesn't
| have that at all, it has very few fixed locations for
| metadata (pretty much just the super blocks). Since no
| assumptions can be made about what's been found in metadata
| areas, it's harder to fix.
|
| So the strategy is different with Btrfs (and probably ZFS too
| since it has a fairly nascent fsck even compared to Btrfs's)
| - cheap and fast replication of data via snapshots and
| send/receive, which requires no deep traversal of either the
| source or destination. And equally cheap and fast restore
| (backwards replication) using the same method. Conversely,
| conventional backup and restore are meaningfully different
| when reversing, so you have to test both the backup and
| restore to really understand if your backup method is
| reliable. That's going to be your disaster go to rather than
| trying to fix them. Fixing is almost certainly going to take
| much longer than restoring. If you don't have current
| backups, at least Btrfs now has various rescue mount options
| to make the file system more tolerant of broken file systems,
| but as a consequence you also have to mount read-only. Pretty
| good chance you can still get your data out, even if it's
| inconvenient to have to wipe the file system and create a new
| one. It'll still be faster than mucking with repair.
|
| Also, Btrfs since kernel 5.3 has both read time and write
| time tree checkers, that verify certain trees for
| consistency, not just blindly accepting checksums. Various
| problems are exposed and stopped before they can cause worse
| problems, and even helps find memory bitflips and btrfs bugs.
| Btrfs doesn't just complain about hardware related issues,
| it'll rat itself out if it's to blame for the problem - which
| at this point isn't happening any more often than ext4 or XFS
| in very large deployments (millions of instances).
| bgorman wrote:
| I have not used BTRFS for years, but I remember at some point a
| BTRFS regression prevented me from booting my system. It is
| hard to regain trust after such a meltdown from such a
| fundamental component. That said, I believe my Synology NAS
| uses btrfs and it has never had an issue.
| F00Fbug wrote:
| I've been in the same boat. Around 2012 or 2013 I put BTRFS
| on my DIY NAS/media server. For some reason, totally
| unprovoked the array just went belly up with no warning or
| logs. I tried and tried without success and couldn't recover
| it. Fortunately I had good, recent backups and restored to
| ext4+LVM and I'm still there 10 years later.
|
| BTRFS sounded cool with all it's new features, but the
| reality is that ext4+LVM does absolutely everything I need
| and it's never given me any issues.
|
| I'm sure BTRFS is much more robust these days, but I'm still
| gun shy!
| stjohnswarts wrote:
| I sort of had the same experience, dropped it for a decade,
| and came back around. It's a lot more robust these days.
| Also the btfsmaintenance tools take a lot of the load off
| of an admin. I just use the default settings and don't have
| any issues.
| danudey wrote:
| In 2019 I was setting up my new computer at my new job, and
| the Ubuntu installer had btrfs as an option. Figuring that
| it had been ages since the last time I'd heard about btrfs
| issues, I opted for that.
|
| A week later, the power failed in the office, and my
| filesystem got corrupted. In the middle of repairing, the
| power dipped again, and my entire fs was unrecoverable
| after that. I managed to get the data off by booting off a
| separate drive and running a command to extract everything,
| but it would never mount no matter what I did.
|
| I've never had an issue with ext4, xfs, or zfs no matter
| how much I've abused them over the past 10+ years, but if
| losing power twice can wipe out my filesystem then no
| thanks, I'm out.
|
| (Plus: non-recursive snapshots? No thanks.)
| silisili wrote:
| Yeah...I used to live in an old neighborhood with above
| ground lines and huuuge trees. Every strong windblow
| would flip the power out for a second. Some days a few
| times a day, some days never.
|
| EXT4 has never once failed me, and I personally battle
| tested it by working while losing power probably a total
| of 200 times. I probably should have bought a UPS come to
| think of it.
| Dylan16807 wrote:
| Was it RAID5/6? If not that's worrying. I've had one
| BTRFS system eat itself to the point that it could only
| be mounted read-only, but no data loss.
| marcodiego wrote:
| What I really want: ext4 performance with instant snapshots plus
| optional transparent compression when it can improve performance.
| There is only one promise to deliver this AFAIK: bcachefs, but it
| still isn't mature yet.
| nisa wrote:
| ZFS on Linux does this pretty well. Performance is close to
| ext4 for most usecases.
| simcop2387 wrote:
| You can actually use a sparse zvol pretty decently for this
| too. You don't get the file level checksumming or some of the
| other features but you can still snapshot the volume and get
| pretty good performance out of it. I've got a few programs
| that don't get along too well with zfs that I use that way.
| R0b0t1 wrote:
| Has anyone used the mentioned associated projects to boot Windows
| off of a BTRFS disk?
|
| Main usecase is storage spaces w/o server or workstation.
| aborsy wrote:
| Any experience on how BTRFS works on laptops, without ECC and
| maybe even one drive (copies =2)?
| 8bitbuddhist wrote:
| Personal anecdote: I've been using BTRFS on my laptop running
| Manjaro for the past year with no issues. Originally I had it
| running in an encrypted LUKS partition on a single Samsung
| NVMe, but for the past month I've been running two NVMe drives
| in RAID 0 with a LUKS volume on top of that and BTRFS inside of
| that. In both cases I've had no performance issues, no
| reliability issues or data loss (even when having to force
| shutdown the laptop due to unrelated freezes), and have been
| able to save and restore from snapshots with zero issues.
| drbawb wrote:
| Although this would be an interesting way to drag some of my old
| NTFS filesystems kicking & screaming into the 21st century, I'd
| never do one of these in-place conversions again. I tried to go
| from ext3 to btrfs several years ago - and it would
| catastrophically fail after light usage. (W're talking less than
| a few hours of desktop-class usage. In retrospect I think it was
| `autodefrag/defragment` that would kill it.) I tried that
| conversion a few times and it never worked, I think I even tried
| to go from ext3->ext4->btrfs. This was on an Arch install so
| (presumably) it was the latest and greatest kernel & userspace
| available at the time.
|
| I eventually gave up (/ got sick of doing restores) and just
| copied the data into a fresh btrfs volume. That worked "great" up
| until I realized (a) I had to turn off CoW for a bunch of things
| I _wanted_ to snapshot, (b) you can 't actually defrag _in
| practice_ because it unlinks shared extents and (c) btrfs on a
| multi-drive array has a failure mode that will leave your root
| filesystem readonly; which is just a footgun that shouldn 't
| exist in a production-facing filesystem. - I should add that
| these were not particularly huge filesytems: the ext3 conversion
| fiasco was ~64G, and my servers were like ~200G and ~100G
| respectively. I also was doing "raid1"/"raid10" style setups, and
| not exercising the supposedly broken raid5/raid6 code in any way.
|
| I think I probably lost three or four filesystems which were
| supposed to be "redundant" before I gave up and switched to ZFS.
| Between (a) & (b) above btrfs just has very few advantages
| compared to ZFS. Really the only thing going for it was being
| available in mainline kernel builds. (Which, frankly, I don't
| consider that to be an advantage the way the GPL zealots on the
| LKML seem to think it is.)
| chasil wrote:
| > ...btrfs just has very few advantages compared to ZFS. Really
| the only thing going for it was being available in mainline
| kernel builds.
|
| ZFS doesn't have defrag, and BtrFS does.
|
| There was a paper recently on purposefully introducing
| fragmentation, and the approach could drastically reduce
| performance on any filesystem that was tested.
|
| This can be fixed in BtrFS. I don't see how to recover from
| this on ZFS, apart from a massive resilver.
|
| https://www.usenix.org/system/files/login/articles/login_sum...
| chasil wrote:
| This set of slides specifically addresses an attack on ZFS
| performance with fragmentation tools.
|
| "Btrfs, ext4, F2FS, XFS, ZFS all age - up to 22x on HDD, up
| to 2x on SSD."
|
| https://pdfs.semanticscholar.org/b743/7111bf04a803878ebacbc2.
| ..
|
| The paper also mentions ZFS:
|
| https://www.cs.unc.edu/~porter/pubs/fast17.pdf
| Dylan16807 wrote:
| I'm pretty dependent on the ability to deduplicate files in
| place without massive overhead. The built in defrag on BTRFS is
| unfortunate but I think you can defragment and re-deduplicate.
|
| I don't know, I'm just hoping for a filesystem that can get
| these features right to come along...
| Flocular wrote:
| In-place conversion of NTFS? You either still believe in a god or
| need to google the price of harddrives these days. Honest
| question tho, why would anybody do in-place conversion of
| partitions?
| drbawb wrote:
| >You either still believe in a god or need to google the price
| of harddrives these days.
|
| That was pretty funny, and I agree a thousand times over. When
| I was younger (read: had shallower pockets) I was willing to
| spend time on these hacks to avoid the need for intermediate
| storage. Now that I'm wiser, crankier, and surrounded by cheap
| storage: I would rather just have Bezos send me a pair of
| drives in <24h to chuck in a sled. They can populate while I'm
| occupied and/or sleeping.
|
| My time spent troubleshooting this crap when it inevitably
| explodes is just not worth the price of a couple of drives; and
| if I still manage to cock everything up at least the latter
| approach leaves me with one or more backup copies. If
| everything goes according to plan well hey the usable storage
| on my NAS just went up ;-). I feel bad for the people that will
| inevitably run this command on the only copy of their data.
| (Though I would hope the userland tool ships w/ plenty of
| warnings to the contrary.)
| marcodiego wrote:
| To save time.
| R0b0t1 wrote:
| Will this actually save time? Not all in-place algos avoid
| copies.
| Jach wrote:
| Maybe if your NTFS drive is less than half full, at least I
| assume this is a limitation of this project since it
| mentions keeping an original copy... Still, belief in god
| seems about right, or you have good backups. I had about
| 2.5 TB on a 3 TB NTFS drive I decided to move over to ZFS,
| just rsynced to a few various drives since I didn't have
| that much contiguous space elsewhere (building a NAS
| later...), learned I had a file whose name is too long for
| either ZFS or ext4 and had to rename it, and after making a
| zpool out of the drive I just rsynced everything back.
| Doing it in place would have saved hours.. but only hours,
| on something not high urgency that doesn't require
| babysitting.
| marwis wrote:
| The backup is a reflink copy as per readme - that means
| data blocks are shared with live filesystem and don't
| occupy extra space but there's probably quite a bit of
| metadata.
| tedunangst wrote:
| > The original image is saved as a reflink copy at
| image/ntfs.img, and if you want to keep the conversion you can
| delete this to free up space.
|
| Now that's really interesting.
| chungy wrote:
| That's in common with the conversion from ext[234] and
| reiserfs, too. Makes it easy to both undo the conversion and
| inspect the original image in case the btrfs metadata became
| wrong somehow.
| fulvioterzapi wrote:
| In place FS conversion looks like black magic to me! Props to the
| authors!!
| prirun wrote:
| In a former life I ran a web site with a co-founder. We needed to
| upgrade our main system (we only had 2), and had mirrored RAID1
| hard drives, some backup but not great. We tested the new system,
| it appeared to work fine, so the plan was to take it to the colo,
| rsync the old system to the new one, make sure everything ran
| okay, then bring the old system home.
|
| We did the rsync, started the new system, it seemed to be working
| okay, but then we started seeing some weird errors. After some
| investigation, it looked like the rsync didn't work right. We
| were tired, it was getting late, so we decided to put one of the
| original mirrors in the new system since we knew it worked.
|
| Started up the new system with the old mirror, it ran for a
| while, then started acted weird too. At that point we only had 1
| mirror left, were beat, and decided to pack the old and new
| system up and bring it all back to the office (my co-founder's
| house!) and figure out what was going on. We couldn't afford to
| lose the last mirror.
|
| After making another mirror in the old system, we started testing
| the new system. It seemed to work fine with 1 disk in either bay
| (it had 2). But when we put them in together and started doing
| I/O from A to B, it corrupted drive A. We weren't even writing to
| drive A!
|
| For the next test, I put both drives on 1 IDE controller instead
| of each on its own controller. (Motherboards had 2 IDE
| controllers, each supported 2 drives). That worked fine.
|
| It turns out there was a defect on the MB and if both IDE ports
| were active, it got confused and sent data to the wrong drive. We
| needed the CPU upgrade so ended up running both drives on 1 IDE
| port and it worked fine until we replaced it a year later.
|
| But we learned a valuable lesson: never ever use your production
| data when doing any kind of upgrade. Make copies, trash them, but
| don't use the originals. I think that lesson applies to the idea
| of doing an inplace conversion from NTFS to Btrfs, even if it
| says it keeps a backup. Do yourself a favor and copy the whole
| drive first, then mess around with the copy.
| gigatexal wrote:
| butter-fs[1] would not be the destination FS I would have chosen
| but such an effort deserves kudos.
|
| [1] ...given how broken it seemingly is, see features that are
| half baked like raid-5. But I am a ZFS snob so don't mind me, my
| fs of choice has it's own issues.
| stryan wrote:
| BTRFS has been stable for years now as long as you don't use
| unsupported features like the aforementioned RAID5. A properly
| set up btrfs system is fine for production use, though note the
| "properly set up" bit, as a good number of distros still don't
| set it up right. I suspect the latter bit is why people
| continue to have issues with it (which is definitely a big
| downside compared to something like ZFS's "no admin
| intervention required" policy).
|
| Regardless, in-place conversion is specifically a feature of
| btrfs due to how its designed. Since it doesn't require a lot
| of fixed metadata, you can convert a fs in-place by throwing
| the btrfs metadata into unallocated space and just point to the
| same blocks as the original fs. I think it even copies the
| original fs's metadata too, so you can mount the filesystem as
| either the original or btrfs for a while.
| ghostly_s wrote:
| I've just lost about a week of my life fighting with a bog-
| simple device replace on a RAID1 btrfs filesystem. I had the
| misfortune of receiving a replacement disk which was also
| bad, and somehow the process of attempting to rebuild the
| array hosed the filesystem on the _good_ disk. Asked for help
| on the irc channel and the only advice I got was "upgrade to
| the latest btrfs-tools" (because apparently the "stable"
| version shipped with debian stable isn't really stable when a
| problem arises?).
|
| I also was misled by btrfs-check which happily scanned my un-
| mountable filesystem with no complaints, and learned on the
| irc that btrfs-check is "an odd duck," in that it doesn't
| actually check all the things the documentation says it does.
|
| This experience, and the fact that simple things like the
| "can only mount a degraded filesystem rw one time" bug remain
| after years of complaints, simply because the devs adopt an
| arrogant "you're doing it wrong if you don't fix your
| filesystem the first time you mount it" (despite the tools
| giving you no indication that's required) attitude, have
| convinced me to never touch btrfs again.
|
| So keep parroting "it's stable!" all you want, my experience
| has shown btrfs is "stable" until you have a problem.
| stryan wrote:
| Debian's actually one of the distros I thought of when I
| said "properly set up". Their tools packages are very out
| of date, they don't install the proper maintenance setup by
| default, and the installer doesn't support subvolumes.
| Going through the man page, yeah I see it does mention
| using btrfs-check for various parts when generally that is
| not recommended (see the Arch Wiki[0] or OpenSUSE docs[1]
| to see how they warn against it).
|
| > So keep parroting "it's stable!" all you want, my
| experience has shown btrfs is "stable" until you have a
| problem. I've been running it on multiple production
| machines for years now, as well as my home machine.
| Facebook has been using it in production for I think over a
| decade now, and it's used by Google and Synology on some of
| their products.
|
| I'm not saying it doesn't have problems (I've certainly
| faced a few), but it is tiresome reading the same cracks
| against it because they set it up without reading the docs.
| You never see the same thing against someone running ZFS
| without regular scrubs or in RAIDZ1.
|
| [0]https://wiki.archlinux.org/title/Btrfs#btrfs_check
|
| [1]https://en.opensuse.org/SDB:BTRFS
| petschge wrote:
| Thing is: I like filesystems that don't eat my data when
| I don't spend a day or two reading the documentation
| before I use them.
| stryan wrote:
| btrfs is default on two distros (that I know of) OpenSUSE
| and Fedora. If you're using one of those two distros,
| don't read the documentation, and then your data is
| eaten/etc then that's fair and you can rightfully be
| upset. I would be too.
|
| But if you're using it in some other setup, then that
| means you went out of your way to try a more complicated
| filesystem. I would think it's reasonable to do at least
| a quick scan of the btrfs wiki or your distro's
| documentation before continuing with that, the same way
| I'd expect someone would do the same for ZFS.
| wolrah wrote:
| > I would think it's reasonable to do at least a quick
| scan of the btrfs wiki or your distro's documentation
| before continuing with that, the same way I'd expect
| someone would do the same for ZFS.
|
| I would argue that the defaults should not be dangerous.
| If a filesystem is released in to the world as stable and
| ready for use, it's not absurd to expect that running
| mkfs.<whatever> /dev/<disk> will get you something that's
| not going to eat your data. It might not be optimized,
| but it shouldn't be dangerous.
|
| Dangerous defaults are loaded footguns and should be
| treated as bugs.
|
| If there is no safe option, there should not be a default
| and the user should be required to explicitly make a
| choice. At that point you can blame them for not reading
| the documentation.
| chungy wrote:
| > You never see the same thing against someone running
| ZFS without regular scrubs or in RAIDZ1.
|
| ZFS doesn't have these kinds of hidden gotchas, and
| that's the key difference. Yeah ok somebody's being dumb
| if they never scrub and find out they have uncorrectable
| bad data come from two drives on a raidz1. That's exactly
| the advertised limitation of raidz1: it can survive a
| single complete drive failure, and can't repair data that
| has been corrupted on two (or more) drives at once.
|
| If you are in the scenario, as the GP was, that you have
| a two-disk mirror and regular scrubs have assured that
| one of the disks has only good data, and the other dies,
| ZFS won't corrupt the data on its own. If you try
| replacing the bad drive with another bad drive,
| eventually the bad drive will fail or produce so many
| errors that ZFS stops trying to use it, and you'll know.
| The pool will continue on with the good drive and tell
| you about it. Then you buy another replacement and hope
| that one is good. No surprises.
| stryan wrote:
| >ZFS doesn't have these kinds of hidden gotchas, and
| that's the key difference. Yeah ok somebody's being dumb
| if they never scrub and find out they have uncorrectable
| bad data come from two drives on a raidz1. That's exactly
| the advertised limitation of raidz1: it can survive a
| single complete drive failure, and can't repair data that
| has been corrupted on two (or more) drives at once.
|
| Why is ZFS requiring scrubs and understanding the
| limitations of it's RAID implementations okay, but btrfs
| requiring scrubs and understanding the limitations of its
| RAID implementations "hidden gotchas"?
|
| > If you are in the scenario, as the GP was, that you
| have a two-disk mirror and regular scrubs have assured
| that one of the disks has only good data, and the other
| dies, ZFS won't corrupt the data on its own. Honestly, I
| don't know enough about GP's situation to really comment
| on what happened there. It could have been btrfs or
| perhaps they were using hardware RAID and the controller
| screwed up. ZFS is definitely very good in that regard
| and I want to be clear that I'm not saying ZFS is bad or
| that btrfs is better then it; I've been using ZFS much
| longer then I have btrfs, back before ZoL was a thing.
| chungy wrote:
| > Why is ZFS requiring scrubs and understanding the
| limitations of it's RAID implementations okay, but btrfs
| requiring scrubs and understanding the limitations of its
| RAID implementations "hidden gotchas"?
|
| It read more like btrfs corrupting data despite good
| scrubbing practice; hosing the file system on the good
| drive instead of letting it remain good, for instance. If
| that's a misreading, that is where my position came from.
|
| Regular scrubs and understanding the limitations of
| redundancy models is good on both systems, yes.
|
| My own anecdotal evidence though: btrfs really does snag
| itself into surprising and disastrous situations at
| alarming frequency. Between being unable to reshape a
| pool (eg, removing a disk when plenty of free space
| exists) and not being safe with unclean shutdowns, it's
| hard to ever trust it. It even went a few good years
| where it seemed to be abandoned, but I guess since 2018
| or so it's been picked up again.
| stryan wrote:
| Ah, I understand what you're saying now. Yeah, that's
| fair assuming it was btrfs's fault for the data loss.
|
| >Between being unable to reshape a pool (eg, removing a
| disk when plenty of free space exists) and not being safe
| with unclean shutdowns, it's hard to ever trust it. It
| even went a few good years where it seemed to be
| abandoned, but I guess since 2018 or so it's been picked
| up again.
|
| FYI, btrfs does support reshaping pool with the btrfs
| device commands.
| vetinari wrote:
| Oh, don't worry, ZFS has a set of its own gotchas.
|
| My favorite is #8885.
| chungy wrote:
| That issue sounds like a configuration error; I don't
| even encounter said "gotcha" on Linux systems.
|
| Even if you grant it to be a simple bug, it's not exactly
| a grave design issue with ZFS.
| Arnavion wrote:
| ZFS is unfortunately not an option if you can't allow
| your kernel to be tainted, whether for idealistic reasons
| or for supportability reasons.
| wpietri wrote:
| It just seems weird to me to still be seeing RTFM more
| than a decade after I last received an actual FM for me
| to R.
|
| A well-designed, general-audience technology product
| doesn't require one to be initiated into the mysteries
| before using it. The phone in my pocket is literally a
| million times more complicated than my first computer and
| I haven't read a bit of documentation. It works fine.
|
| If btrfs wants to be something people use, its promoters
| need to stop blaming users for bad outcomes and start
| making it so that the default setup is what people need
| to get results at least as good as the competition. I
| have never read an extfs manual, but when I've had
| problems nobody has ever blamed bad outcomes on me not
| reading an extfs manual.
| notyourday wrote:
| Btrfs has not been, is currently not, and unlikely in
| future to become a general population usable file system,
| which is a shame as 10 years ago it looked like a
| promising move forward.
|
| Its window to it was when setting up ZFS included lots of
| hand-waving. That window now has closed. ZFS is sable,
| does not eat data, does not have a cult of wizards
| spelling "RTFM" and is can be installed in major
| distributions using easy to follow procedure. In a year
| or two I expect that procedure to be fully automated, to
| a point where one could do a root on ZFS.
| drbawb wrote:
| I haven't tried this yet but supposedly the Ubuntu
| installer can setup ZFS on root for a very basic[1]
| install. (i.e: No redundancy, and no encryption. The
| former one could trivially add after the fact by
| attaching a mirror & doing a scrub. The latter you could
| also do post-install w/ some zfs send+recv shenanigans,
| and maybe some initramfs changes.)
|
| I do use the Ubuntu live image pretty regularly when I
| need to import zpools in a preboot environment and it
| works great. In general it's not my favorite distro - but
| I'm happy to see they're doing some of the leg work to
| bring ZFS to a wider audience.
|
| [1]: https://openzfs.github.io/openzfs-
| docs/Getting%20Started/Ubu...
| wolrah wrote:
| > In a year or two I expect that procedure to be fully
| automated, to a point where one could do a root on ZFS.
|
| Ubuntu has been able to install directly to root-on-ZFS
| automatically since 20.04. I don't think any other major
| distros are as aggressive about supporting ZFS due to the
| licensing problem, but the software is already there.
| roblabla wrote:
| > (because apparently the "stable" version shipped with
| debian stable isn't really stable when a problem arises?).
|
| "Stable" here means "unchanging". It doesn't mean bug-free.
| My personal experience is, you'll generally encounter
| _less_ bugs on a rolling release distro (like arch) or
| distros with frequent updates (like fedora). The upside of
| stable distros (like debian) is that new bugs (or other
| breaking changes) won 't be introduced during the distro's
| release lifetime.
| Already__Taken wrote:
| I wasted far too much of my life fixing stuff that
| already has fixes released 6 years ago because "oh we
| should use 'stable'"
| gigatexal wrote:
| Every other fs works without tweaks. Having to fiddle with a
| fs to get it just right means it's not production grade.
|
| Who fiddles with ext4 or xfs after formatting it?
| LukeShu wrote:
| What are distros doing to set it up wrong?
|
| (I've been a happy user of btrfs for several years now
| https://news.ycombinator.com/item?id=21446761)
| stryan wrote:
| To be clear, I'm not saying distros are setting it up
| "wrong" just not..correctly? As in, if I setup a filesystem
| I would assume most distros would set it up with best
| practices in mind.
|
| What I'm trying to convey is most of the time when I help
| someone out with btrfs issues it always turns out they
| haven't been running regular scrubs or balances and their
| distro didn't setup anything so they didn't know. Or they
| don't understand how much diskspace they have because their
| distro's docs still have them running du instead of "btrfs
| filesystem usage".
|
| For specific distros, arch/arch-derivatives had autodefrag
| as a default mount option which caused some thrashing a
| while back and IIRC Debian still doesn't support subvolumes
| properly, as well as not installing btrfs-maintenance.
| sp332 wrote:
| > BTRFS has been stable for years now
|
| As far as I can tell, that is true. But given the number of
| years it spent broken, the amount of time I spent recovering
| broken arrays, and the (unknown but >0) number of my files
| that it ate, you'll forgive me for not being enthusiastic
| now.
| unmole wrote:
| > butter-fs
|
| You thought that'd be a swipe but that's how the developers
| pronounce it
| IgorPartola wrote:
| Isn't there another FS called butter-fs that is separate from
| BTRFS?
| loeg wrote:
| One of the other pronunciations of btrfs is "Better-FS,"
| and there is another one of those -- BeTRFS (B-epsilon tree
| FS).
| karmakaze wrote:
| I used btrfs on an EC2 instance with two local SSDs that were
| mirrored for a CI pipeline running Concourse. It would botch up
| every few months, and I got to automating setup so that it was
| easy to recreate. I never did find the actual source of the
| instance botch-up though. It was either the local PostgreSQL
| instance running on btrfs, btrfs, or the Concourse software. I
| pretty much ruled out the PostgreSQL being the originating source
| of the issue, but didn't get further than that. I don't know if
| anyone would suspect mdadm.
|
| Other than whatever that instability was, I can say that the
| performance was exceptional and would use that setup again, with
| more investigation into causes of the instability.
___________________________________________________________________
(page generated 2022-03-07 23:00 UTC)