Tweet
Originally posted by jaxad0127
View Post
-
Not. Good. Enough.
-
online reduce/enlarge and fsck are a mst.
aix support online resizing, and its a charm.. but they support it for ages..Comment
-
I have a server. I want to "migrate". How do I "migrate" from XFS V4 to V5? I can't. I have to recreate, which, at that point can be btrfs or zfs or whatever. Not "in-place" migration basically means "create anew", which is lame af.Originally posted by Vistaus View PostComment
-
-
Still my mega video store go-to. Been around for ever, and obviously intend on going nowhere.HiComment
-
And is there way to migrate that without service interruption and total FS re-creation? Would old volumes stay at least R/O mountable after this point? Well, guess I've got spoiled by btrfs that does most things on-line and without FS re-creation. Even going for different compression or checksumming algos, raid levels, etc.Code:thus users have a decade to upgrade to the newer V5 format.
I'd say it's problem is that it... unpopular/abandoned and arrived just too late for it's kind of the thing. Seems out of CoW-like when it comes to Linux most of interesting stuff goes around btrfs. Which is quite well tested due to Facebook deployment, fairly active and got far more interesting features. That are not even backfire on you most of time now due to extensive testing - and it'd debatable if NILFS can boast comparable code quality and coverage as there're apparently far less users and tests. So it comes down to question how reliable it would be in the wild, would it keep data, how to recover it if wouldn't, etc. Say, data checksumming proven to be really good thing: you could know your HW fails you before it escalates into major problem.Originally posted by Old Grouch View Post
I'd say e.g. btrfs gets without "classic" fsck tool - just because CoW and somesuch can afford different approach to recovery after crash. Under normal circumstances, CoW design could just discard troublesome incomplete changes and .. basically go with previous, consistent state that wasn't touched by last writes. That's whole point of CoW/Log Structured/whatever name you call it. At this point it makes no real sense to do FSCK, it's an attribute of classic designs that don't take consistent state after crash as something granted at all, therefore facing need to run fsck - mounting inconsistent data/metadata filesystem is crappy idea. This said it doesn't hurt to have online background scan ("scrub") and "hardcore recovery" tools when things gone weird (e.g. storages spit garbage/bad sectors/other strange crap). At this point I would think it's debatable whether fsck is feature. From systems management point of view this venerable thing is actually pain in the rear that can turn boot times into nightmare on modern volumes. Just because scanning truckloads of data on large hierarchies isn't necessarily something fast that you may want as part of your boot sequence. And it's a bit too late when it's already mounted in classic designs. So I'd say in modern world classic fsck approach leaves a lot to be desired. It doesn't scales!- fsck
- Extended attributes
Actually, are there someone who dared to put data and at least do numerous resets/powerloss tests on that thing? I've did that for btrfs and I failed to crash it in a fatal manner, EXT3/4 that lose some data or play pranks but are mostly recoverable by fsck and also F2FS, that one eventually gone total nuts, reaching state neither it can mount, nor it's fsck can fix that, at which point you obviously have a problem it it wasn't a test run where you can just scrap it.so I do not advocate it as a file system panacea.Last edited by SystemCrasher; 21 October 2020, 11:27 AM.Comment
-
But still, that should be possible within 10 years.Originally posted by arcivanov View PostComment
-
People don't resize their partitions all the time.Originally posted by bash2bash View Post
RHEL and Fedora Server default to XFS. Go ahead and tell the most successful GNU/Linux distributor ever how stupid they are.Comment
-
Yes, me. I run with NILFS2 as my root and separate home and var volumes. Have done so for many years, with one problem caused by changing kernel behaviour, documented in the kernel mailing list. As it is my daily driver laptop, it has had a number of hard power-offs without issue. I've not done formal testing.Originally posted by SystemCrasher View Post
However, I will emphasize that I do not advocate it for all. I do have backups, and my business is not reliant on it. One of the main drivers for me using it is the excellent file-level checkpoint/snapshotting capability, as I missed the VAX/VMS file-versioning. As it happens, I have very rarely needed to roll back files, or indeed, recover accidentally deleted ones without needing to go and look for a recent backup - but it it nice having the capability.
It could well be that NILFS2 does not meet your use-case, which is fine. I don't claim it does everything, or is fit for all reasonable purposes. It works for me, and I am grateful for its existence.Last edited by Old Grouch; 21 October 2020, 03:34 PM.Comment
-
Actually, they do that VERY frequently in the cloud business. Thousands of servers get resized daily, into a smaller version or larger one. For various reasons, like taking advantage of pricing per hour, thus one can grow servers during a black friday event and then shrink them back down to their previous size, once the event is over.
Unfortunately, the business sector does not bother to tell RedHat anything, instead they have already created their own RHEL and CentOS images that use ext4 by default and scrapped xfs a long time ago. One such cloud provider is Linode.
Fedora has already scrapped xfs for btrfs, so yes, xfs is already a footnote in the file system history...
Originally posted by Awesomeness View PostComment
Comment