fsck: to repair or not to repair
Hello,
I recently ran btrfsck on one of my file systems, and got the following messages:
checking extents
checking free space cache
checking fs roots
root 5 inode 3149867 errors 400, nbytes wrong root 5 inode 3150237 errors 400, nbytes wrong root 5 inode 3150238 errors 400, nbytes wrong root 5 inode 3150242 errors 400, nbytes wrong root 5 inode 3150260 errors 400, nbytes wrong
[ lots of similar message with different inode numbers ] root 5 inode 15595011 errors 400, nbytes wrong root 5 inode 15595016 errors 400, nbytes wrong Checking filesystem on /dev/mapper/vg0-nikratio_crypt
UUID: 8742472d-a9b0-4ab6-b67a-5d21f14f7a38 found 263648960636 bytes used err is 1
total csum bytes: 395314372
total tree bytes: 908644352
total fs tree bytes: 352735232
total extent tree bytes: 95039488
btree space waste bytes: 156301160
file data blocks allocated: 675209801728
referenced 410351722496
Btrfs v3.17
Can someone explain to me the risk that I run by attempting a repair, and (conversely) what I put at stake when continuing to use this file system as-is?
Best,
-Nikolaus
Signature · 4 lines
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«Quoted 30 lines · Nikolaus Rath
Hello,
I recently ran btrfsck on one of my file systems, and got the following messages:
checking extents
checking free space cache
checking fs roots
root 5 inode 3149867 errors 400, nbytes wrong root 5 inode 3150237 errors 400, nbytes wrong root 5 inode 3150238 errors 400, nbytes wrong root 5 inode 3150242 errors 400, nbytes wrong root 5 inode 3150260 errors 400, nbytes wrong
[ lots of similar message with different inode numbers ] root 5 inode 15595011 errors 400, nbytes wrong root 5 inode 15595016 errors 400, nbytes wrong Checking filesystem on/dev/mapper/vg0-nikratio_crypt
UUID: 8742472d-a9b0-4ab6-b67a-5d21f14f7a38 found 263648960636 bytes used err is 1
total csum bytes: 395314372
total tree bytes: 908644352
total fs tree bytes: 352735232
total extent tree bytes: 95039488
btree space waste bytes: 156301160
file data blocks allocated: 675209801728
referenced 410351722496
Btrfs v3.17
Quoted 3 lines
Can someone explain to me the risk that I run by attempting a repair, and (conversely) what I put at stake when continuing to use this file system as-is?
It has once been mentioned in this mail-list, that if the 'errors 400, nbytes wrong' is the only error on an fs, btrfs check --repair can fix them ( was around time of tools release 4.4 , by Qu AFAIK). I had /(have?) about 7 of those errors in small files on an fs that is 2.5 years old and has quite some older ro snapshots. I once tried to fix them with 4.5.0 + some patches tools, but actually they did not get fixed. At least with 4.5.2 or 4.5.3 tools it should be possible to fix them in your case. Maybe you first want to test it on an overlay of the device or copy the whole fs with dd. It depends on how much time you can allow the fs to be offline etc, it is up to you.
In my case, I recreated the files in the working subvol, but as long as I don't remove the older snapshots, the errors 400 will still be there I assume. At least I don't experience any negative impact of it, so I keep it like it is until at some point in time the older snapshots get removed or I am somehow forced to clone back the data into a fresh fs. I am running mostly latest stable or sometimes mainline kernel.
Quoted 46 lines · Henk Slager
Quoted 30 lines · Nikolaus Rath
Hello,
I recently ran btrfsck on one of my file systems, and got the following messages:
checking extents
checking free space cache
checking fs roots
root 5 inode 3149867 errors 400, nbytes wrong root 5 inode 3150237 errors 400, nbytes wrong root 5 inode 3150238 errors 400, nbytes wrong root 5 inode 3150242 errors 400, nbytes wrong root 5 inode 3150260 errors 400, nbytes wrong
[ lots of similar message with different inode numbers ] root 5 inode 15595011 errors 400, nbytes wrong root 5 inode 15595016 errors 400, nbytes wrong Checking filesystem on/dev/mapper/vg0-nikratio_crypt
UUID: 8742472d-a9b0-4ab6-b67a-5d21f14f7a38 found 263648960636 bytes used err is 1
total csum bytes: 395314372
total tree bytes: 908644352
total fs tree bytes: 352735232
total extent tree bytes: 95039488
btree space waste bytes: 156301160
file data blocks allocated: 675209801728
referenced 410351722496
Btrfs v3.17Quoted 3 lines
Can someone explain to me the risk that I run by attempting a repair, and (conversely) what I put at stake when continuing to use this file system as-is?
It has once been mentioned in this mail-list, that if the 'errors 400, nbytes wrong' is the only error on an fs, btrfs check --repair can fix them ( was around time of tools release 4.4 , by Qu AFAIK). I had /(have?) about 7 of those errors in small files on an fs that is 2.5 years old and has quite some older ro snapshots. I once tried to fix them with 4.5.0 + some patches tools, but actually they did not get fixed. At least with 4.5.2 or 4.5.3 tools it should be possible to fix them in your case. Maybe you first want to test it on an overlay of the device or copy the whole fs with dd. It depends on how much time you can allow the fs to be offline etc, it is up to you.
Quoted 1 line
In my case, I recreated the files in the working subvol, but as long
[...]
How did you determine which files were affected? Is there a way to map inodes to paths?
Thanks!
-Nikolaus
Signature · 4 lines
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«Quoted 46 lines · Nikolaus Rath
Quoted 45 lines · Henk Slager
Quoted 30 lines · Nikolaus Rath
Hello,
I recently ran btrfsck on one of my file systems, and got the following messages:
checking extents
checking free space cache
checking fs roots
root 5 inode 3149867 errors 400, nbytes wrong root 5 inode 3150237 errors 400, nbytes wrong root 5 inode 3150238 errors 400, nbytes wrong root 5 inode 3150242 errors 400, nbytes wrong root 5 inode 3150260 errors 400, nbytes wrong
[ lots of similar message with different inode numbers ] root 5 inode 15595011 errors 400, nbytes wrong root 5 inode 15595016 errors 400, nbytes wrong Checking filesystem on/dev/mapper/vg0-nikratio_crypt
UUID: 8742472d-a9b0-4ab6-b67a-5d21f14f7a38 found 263648960636 bytes used err is 1
total csum bytes: 395314372
total tree bytes: 908644352
total fs tree bytes: 352735232
total extent tree bytes: 95039488
btree space waste bytes: 156301160
file data blocks allocated: 675209801728
referenced 410351722496
Btrfs v3.17Quoted 3 lines
Can someone explain to me the risk that I run by attempting a repair, and (conversely) what I put at stake when continuing to use this file system as-is?
It has once been mentioned in this mail-list, that if the 'errors 400, nbytes wrong' is the only error on an fs, btrfs check --repair can fix them ( was around time of tools release 4.4 , by Qu AFAIK). I had /(have?) about 7 of those errors in small files on an fs that is 2.5 years old and has quite some older ro snapshots. I once tried to fix them with 4.5.0 + some patches tools, but actually they did not get fixed. At least with 4.5.2 or 4.5.3 tools it should be possible to fix them in your case. Maybe you first want to test it on an overlay of the device or copy the whole fs with dd. It depends on how much time you can allow the fs to be offline etc, it is up to you.
Quoted 5 lines
Quoted 1 line
In my case, I recreated the files in the working subvol, but as long
[...]
How did you determine which files were affected? Is there a way to map inodes to paths?
btrfs inspect-internal inode-resolve <inode> <path>.
This resolves the <inode> in subvol <path> to its fs paths
Thanks,
Ashish
Quoted 5 lines
Thanks!
-Nikolaus
Henk Slager posted on Thu, 12 May 2016 19:02:56 +0200 as excerpted:
Quoted 2 lines
Maybe you first want to test it on an overlay
of the device or copy the whole fs with dd.
WARNING!
Because btrfs can be multi-device, it needs some way to track which devices belong to each filesystem, and it uses filesystem UUID for this purpose.
If you clone a filesystem (for instance using dd or lvm snapshotting, doesn't matter how) and then trigger a btrfs device scan, say by plugging in some other device with btrfs on it so udev triggers a scan, and the kernel sees multiple devices with the same filesystem UUID as a result, and one of those happens to be mounted, you can corrupt both copies as the kernel btrfs won't be able to tell them apart and may write updates to the wrong one.
Prevention:
Don't let btrfs see both copies at the same time. If you need to clone the filesystem, ideally make sure it's unmounted at the time, and detach either the original device or the clone immediately upon finishing the clone operation (before doing anything that might trigger a btrfs device scan, including device plugging that would trigger udev to trigger such a scan). Then simply keep them separate, only attaching one at a time and DEFINITELY never mounting the filesystem with both the clone and the original devices attached, so the kernel can't get confused and write to the wrong one because the other one is never there at the same time to provide the opportunity.
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Quoted 11 lines · Duncan
Because btrfs can be multi-device, it needs some way to track which devices belong to each filesystem, and it uses filesystem UUID for this purpose.
If you clone a filesystem (for instance using dd or lvm snapshotting, doesn't matter how) and then trigger a btrfs device scan, say by plugging in some other device with btrfs on it so udev triggers a scan, and the kernel sees multiple devices with the same filesystem UUID as a result, and one of those happens to be mounted, you can corrupt both copies as the kernel btrfs won't be able to tell them apart and may write updates to the wrong one.
That seems like a rather odd design. Why isn't btrfs refusing to mount in this situation? In the face of ambiguity, guessing is generally bad idea (at least for a computer program).
Best,
-Nikolaus
Signature · 4 lines
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«Quoted 13 lines · Nikolaus Rath
Quoted 11 lines · Duncan
Because btrfs can be multi-device, it needs some way to track which devices belong to each filesystem, and it uses filesystem UUID for this purpose.
If you clone a filesystem (for instance using dd or lvm snapshotting, doesn't matter how) and then trigger a btrfs device scan, say by plugging in some other device with btrfs on it so udev triggers a scan, and the kernel sees multiple devices with the same filesystem UUID as a result, and one of those happens to be mounted, you can corrupt both copies as the kernel btrfs won't be able to tell them apart and may write updates to the wrong one.
Quoted 3 lines
That seems like a rather odd design. Why isn't btrfs refusing to mount in this situation? In the face of ambiguity, guessing is generally bad idea (at least for a computer program).
The logic you describe requires code. It's the absence of code rather than an intentional design that's the cause of the current behavior. And yes, it'd be nice if Btrfs weren't stepping on its own tail in this situation. It could be as simple as refusing to mount anytime there's an ambiguity, but that's sorta user hostile if there isn't a message that goes along with it to help the user figure out a way to resolve the problem. And that too could be fraught with peril if the user makes a mistake. So, really what's the right way to do this is part of the problem but I agree it's better to be hostile and refuse to mount a given volume UUID at all when too many devices are found, than corrupt the file system.
Signature · 1 line
Chris Murphy
Quoted 18 lines · Chris Murphy
Quoted 13 lines · Nikolaus Rath
Quoted 11 lines · Duncan
Because btrfs can be multi-device, it needs some way to track which devices belong to each filesystem, and it uses filesystem UUID for this purpose.
If you clone a filesystem (for instance using dd or lvm snapshotting, doesn't matter how) and then trigger a btrfs device scan, say by plugging in some other device with btrfs on it so udev triggers a scan, and the kernel sees multiple devices with the same filesystem UUID as a result, and one of those happens to be mounted, you can corrupt both copies as the kernel btrfs won't be able to tell them apart and may write updates to the wrong one.
Quoted 3 lines
That seems like a rather odd design. Why isn't btrfs refusing to mount in this situation? In the face of ambiguity, guessing is generally bad idea (at least for a computer program).
Quoted 12 lines
The logic you describe requires code. It's the absence of code rather than an intentional design that's the cause of the current behavior. And yes, it'd be nice if Btrfs weren't stepping on its own tail in this situation. It could be as simple as refusing to mount anytime there's an ambiguity, but that's sorta user hostile if there isn't a message that goes along with it to help the user figure out a way to resolve the problem. And that too could be fraught with peril if the user makes a mistake. So, really what's the right way to do this is part of the problem but I agree it's better to be hostile and refuse to mount a given volume UUID at all when too many devices are found, than corrupt the file system.
FWIW, the behavior I'd expect from a sysadmin perspective would be:
1. If and only if a correct number of device= options have been passed to mount, use those devices (and only those devices), and log a warning if extra devices are detected.
2. Otherwise, refuse to mount and log a warning.
16.05.2016 14:17, Austin S. Hemmelgarn пишет:
Quoted 32 lines · Chris Murphy
Quoted 19 lines · Nikolaus Rath
Quoted 14 lines · Duncan
Quoted 4 lines
Because btrfs can be multi-device, it needs some way to track which devices belong to each filesystem, and it uses filesystem UUID for this purpose.
Quoted 8 lines
If you clone a filesystem (for instance using dd or lvm snapshotting, doesn't matter how) and then trigger a btrfs device scan, say by plugging
in some other device with btrfs on it so udev triggers a scan, and the kernel sees multiple devices with the same filesystem UUID as a result, and one of those happens to be mounted, you can corrupt both copies as the kernel btrfs won't be able to tell them apart and may write updates to the wrong one.Quoted 3 lines
That seems like a rather odd design. Why isn't btrfs refusing to mount in this situation? In the face of ambiguity, guessing is generally bad idea (at least for a computer program).
Quoted 12 lines
The logic you describe requires code. It's the absence of code rather than an intentional design that's the cause of the current behavior. And yes, it'd be nice if Btrfs weren't stepping on its own tail in this situation. It could be as simple as refusing to mount anytime there's an ambiguity, but that's sorta user hostile if there isn't a message that goes along with it to help the user figure out a way to resolve the problem. And that too could be fraught with peril if the user makes a mistake. So, really what's the right way to do this is part of the problem but I agree it's better to be hostile and refuse to mount a given volume UUID at all when too many devices are found, than corrupt the file system.
Quoted 4 lines
FWIW, the behavior I'd expect from a sysadmin perspective would be:
1. If and only if a correct number of device= options have been passed to mount, use those devices (and only those devices), and log a warning if extra devices are detected.
First, how do you know that devices, passed as device= options, are correct? Is it possible to detect stale copy?
Second, today udev rules will run equivalent of "btrfs device ready" for each device that is part of btrfs. So you still need to handle the situation when device(s) appear and disappear after initial mount and have some way to distinguish between two copies.
Third, what exactly "extra devices detected" means? Who is responsible for detection? Where this information is kept? How can mount query this information?
Quoted 1 line
2. Otherwise, refuse to mount and log a warning.
So no way to mount degraded redundant filesystem?
Quoted 33 lines · Andrei Borzenkov
16.05.2016 14:17, Austin S. Hemmelgarn пишет:
Quoted 32 lines · Chris Murphy
Quoted 31 lines · Nikolaus Rath
Quoted 14 lines · Duncan
Quoted 4 lines
Because btrfs can be multi-device, it needs some way to track which devices belong to each filesystem, and it uses filesystem UUID for this purpose.
Quoted 8 lines
If you clone a filesystem (for instance using dd or lvm snapshotting, doesn't matter how) and then trigger a btrfs device scan, say by plugging
in some other device with btrfs on it so udev triggers a scan, and the kernel sees multiple devices with the same filesystem UUID as a result, and one of those happens to be mounted, you can corrupt both copies as the kernel btrfs won't be able to tell them apart and may write updates to the wrong one.Quoted 3 lines
That seems like a rather odd design. Why isn't btrfs refusing to mount in this situation? In the face of ambiguity, guessing is generally bad idea (at least for a computer program).
The logic you describe requires code. It's the absence of code rather than an intentional design that's the cause of the current behavior. And yes, it'd be nice if Btrfs weren't stepping on its own tail in this situation. It could be as simple as refusing to mount anytime there's an ambiguity, but that's sorta user hostile if there isn't a message that goes along with it to help the user figure out a way to resolve the problem. And that too could be fraught with peril if the user makes a mistake. So, really what's the right way to do this is part of the problem but I agree it's better to be hostile and refuse to mount a given volume UUID at all when too many devices are found, than corrupt the file system.
Quoted 7 lines
Quoted 4 lines
FWIW, the behavior I'd expect from a sysadmin perspective would be:
1. If and only if a correct number of device= options have been passed to mount, use those devices (and only those devices), and log a warning if extra devices are detected.First, how do you know that devices, passed as device= options, are correct? Is it possible to detect stale copy?
You don't. As much as it pains me to say it, there's no way to protect against this reliably. The intent is that if you have specified the correct number of devices according to the number the filesystem says should be there (and that number is the same on all devices specified), it's assumed you know what you're doing.
Quoted 3 lines
Second, today udev rules will run equivalent of "btrfs device ready" for each device that is part of btrfs.
That's part of the rules shipped by systemd, and is not by any means on every system in existence. That is an inherent design flaw in systemd resulting from them thinking they're smarter than the kernel, and it has on multiple occasions bit people.
Quoted 3 lines
So you still need to handle the
situation when device(s) appear and disappear after initial mount and have some way to distinguish between two copies.
Yes, you need to account for devices appearing and disappearing, but at least until we add proper support for off-line devices, that's easy.
Quoted 4 lines
Third, what exactly "extra devices detected" means? Who is responsible for detection? Where this information is kept? How can mount query this information?
If there are more devices with the filesystem's UUID than are passed in via device= options, and the above stated condition regarding device= options is met, then those are extra devices.
Quoted 4 lines
Quoted 2 lines
2. Otherwise, refuse to mount and log a warning.
So no way to mount degraded redundant filesystem?
I know a large number of people who routinely use degraded as part of their fstab options. Degraded is supposed to mean reduced data safety, not 'may cause random corruption just by being used'. I have no issue with a mount option to force mounting it anyway, but I absolutely do not want that to be part of the degraded mount option.
Quoted 29 lines · Nikolaus Rath
Hello,
I recently ran btrfsck on one of my file systems, and got the following messages:
checking extents
checking free space cache
checking fs roots
root 5 inode 3149867 errors 400, nbytes wrong root 5 inode 3150237 errors 400, nbytes wrong root 5 inode 3150238 errors 400, nbytes wrong root 5 inode 3150242 errors 400, nbytes wrong root 5 inode 3150260 errors 400, nbytes wrong
[ lots of similar message with different inode numbers ] root 5 inode 15595011 errors 400, nbytes wrong root 5 inode 15595016 errors 400, nbytes wrong Checking filesystem on/dev/mapper/vg0-nikratio_crypt
UUID: 8742472d-a9b0-4ab6-b67a-5d21f14f7a38 found 263648960636 bytes used err is 1
total csum bytes: 395314372
total tree bytes: 908644352
total fs tree bytes: 352735232
total extent tree bytes: 95039488
btree space waste bytes: 156301160
file data blocks allocated: 675209801728
referenced 410351722496
Btrfs v3.17
Quoted 3 lines
Can someone explain to me the risk that I run by attempting a repair, and (conversely) what I put at stake when continuing to use this file system as-is?
To follow-up on this: after finding out which files were affected (using btrfs inspect-internal), I was able to fix the problem without using btrfsck by simply copying the data, deleting the file, and restoring it:
cat affected-files.txt | while read -r name; do
rsync -a "${name}" "/backup/location/${name}"
rm -f "${name}"
cp -a "/backup/location/${name}" "${name}"
done
(I used rsync to avoid cp making use of reflinks). After this procedure, btrfschk reported no more problems.
Best,
-Nikolaus
Signature · 4 lines
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«Quoted 38 lines · Nikolaus Rath
Quoted 29 lines · Nikolaus Rath
Hello,
I recently ran btrfsck on one of my file systems, and got the following messages:
checking extents
checking free space cache
checking fs roots
root 5 inode 3149867 errors 400, nbytes wrong root 5 inode 3150237 errors 400, nbytes wrong root 5 inode 3150238 errors 400, nbytes wrong root 5 inode 3150242 errors 400, nbytes wrong root 5 inode 3150260 errors 400, nbytes wrong
[ lots of similar message with different inode numbers ] root 5 inode 15595011 errors 400, nbytes wrong root 5 inode 15595016 errors 400, nbytes wrong Checking filesystem on/dev/mapper/vg0-nikratio_crypt
UUID: 8742472d-a9b0-4ab6-b67a-5d21f14f7a38 found 263648960636 bytes used err is 1
total csum bytes: 395314372
total tree bytes: 908644352
total fs tree bytes: 352735232
total extent tree bytes: 95039488
btree space waste bytes: 156301160
file data blocks allocated: 675209801728
referenced 410351722496
Btrfs v3.17Quoted 3 lines
Can someone explain to me the risk that I run by attempting a repair, and (conversely) what I put at stake when continuing to use this file system as-is?
To follow-up on this: after finding out which files were affected (using btrfs inspect-internal), I was able to fix the problem without using btrfsck by simply copying the data, deleting the file, and restoring it:
Quoted 8 lines
cat affected-files.txt | while read -r name; do
rsync -a "${name}" "/backup/location/${name}"
rm -f "${name}"
cp -a "/backup/location/${name}" "${name}"
done(I used rsync to avoid cp making use of reflinks). After this procedure, btrfschk reported no more problems.
JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid it making reflinks.
Quoted 2 lines · Austin S. Hemmelgarn
JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid it making reflinks.
I would have expected so, but at least in coreutils 8.23 the only valid options are "never" and "auto" (at least according to cp --help and the manpage).
Best,
-Nikolaus
Signature · 4 lines
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«Quoted 7 lines · Nikolaus Rath
Quoted 2 lines · Austin S. Hemmelgarn
JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid it making reflinks.
I would have expected so, but at least in coreutils 8.23 the only valid options are "never" and "auto" (at least according to cp --help and the manpage).
Where do you get "never" from?
.--====
cp: invalid argument ‘never’ for ‘--reflink’
Valid arguments are:
- ‘auto’
- ‘always’
Try 'cp --help' for more information.
`----
And, as of coreutils 8.25, the default is no reflink, with "never" not being recognized even as a way to avoid an alias. As far as I remember, this applies to every past version with support for reflinks too.
Signature · 1 line
An imaginary friend squared is a real enemy.
Quoted 10 lines · Adam Borowski
Quoted 7 lines · Nikolaus Rath
Quoted 2 lines · Austin S. Hemmelgarn
JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid it making reflinks.
I would have expected so, but at least in coreutils 8.23 the only valid options are "never" and "auto" (at least according to cp --help and the manpage).
Where do you get "never" from?
I meant to write "always" (as in my second mail, I thought I hit "cancel" quickly enough).
Best,
-Nikolaus
Signature · 4 lines
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«Quoted 19 lines · Adam Borowski
Quoted 7 lines · Nikolaus Rath
Quoted 2 lines · Austin S. Hemmelgarn
JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid it making reflinks.
I would have expected so, but at least in coreutils 8.23 the only valid options are "never" and "auto" (at least according to cp --help and the manpage).
Where do you get "never" from?
.--====
cp: invalid argument ‘never’ for ‘--reflink’
Valid arguments are:
- ‘auto’
- ‘always’
Try 'cp --help' for more information.
`----
Quoted 4 lines
And, as of coreutils 8.25, the default is no reflink, with "never" not being recognized even as a way to avoid an alias. As far as I remember, this applies to every past version with support for reflinks too.
Odd, I could have sworn that was an option...
And I do know there was talk at least at one point of adding it and switching to reflink=auto by default.
Quoted 9 lines · Austin S. Hemmelgarn
Quoted 4 lines · Adam Borowski
And, as of coreutils 8.25, the default is no reflink, with "never" not being recognized even as a way to avoid an alias. As far as I remember, this applies to every past version with support for reflinks too.
Odd, I could have sworn that was an option...
And I do know there was talk at least at one point of adding it and switching to reflink=auto by default.
Yes please!
It's hard to come with a good reason for not reflinking when it's possible -- the only one I see is if you have a nocow VM and want to slightly improve speed at a cost of lots of disk space. And even then, there's cat a >b for that.
And the cost on non-btrfs non-unmerged-xfs is a single syscall per file, that's utterly negligible compared to actually copying the data.
Signature · 1 line
An imaginary friend squared is a real enemy.
Quoted 11 lines · Adam Borowski
Quoted 9 lines · Austin S. Hemmelgarn
Quoted 4 lines · Adam Borowski
And, as of coreutils 8.25, the default is no reflink, with "never" not being recognized even as a way to avoid an alias. As far as I remember, this applies to every past version with support for reflinks too.
Odd, I could have sworn that was an option...
And I do know there was talk at least at one point of adding it and switching to reflink=auto by default.
Quoted 6 lines
Yes please!
It's hard to come with a good reason for not reflinking when it's possible -- the only one I see is if you have a nocow VM and want to slightly improve speed at a cost of lots of disk space. And even then, there's cat a >b for that.
There are other arguments, the most common one being not changing user visible behavior. There are (misguided) people who expect copying a file to mean you have two distinct copies of that file.
OTOH, it's not too hard to set up a system to do this, you just put:
alias cp='cp --reflink=auto'
into your bashrc (or something similar into whatever other shell you use). I've been doing this since cp added support for it.
Quoted 3 lines
And the cost on non-btrfs non-unmerged-xfs is a single syscall per file, that's utterly negligible compared to actually copying the data.
Actually, IIRC, it's an ioctl, not a syscall, which can be kind of expensive (I don't know how much more expensive, but ioctls are usually more expensive than syscalls).
Other things to keep in mind though that may impact this (either way):
1. There are other filesystems that support reflinks (OCFS2 and ZFS come immediately to mind).
2. Most of the filesystems that support reflinks are used more in enterprise situations, where the bit about not changing user visible behavior is a much stronger argument.
3. Even in enterprise situations, reflink capable filesystems are still unusual outside of petabyte scale data storage.
4. Last I checked, the most widely used filesystem that supports reflinks (ZFS) uses a different ioctl interface for them than most other Linux filesystems, which means more checking is needed than just calling one ioctl.
Quoted 11 lines · Adam Borowski
Quoted 9 lines · Austin S. Hemmelgarn
Quoted 4 lines · Adam Borowski
And, as of coreutils 8.25, the default is no reflink, with "never" not being recognized even as a way to avoid an alias. As far as I remember, this applies to every past version with support for reflinks too.
Odd, I could have sworn that was an option...
And I do know there was talk at least at one point of adding it and switching to reflink=auto by default.
Quoted 6 lines
Yes please!
It's hard to come with a good reason for not reflinking when it's possible -- the only one I see is if you have a nocow VM and want to slightly improve speed at a cost of lots of disk space. And even then, there's cat a >b for that.
For a nocow VM imagefile, reflink anyhow does not work so cp --reflink=auto would then just duplicate the whole thing, do doing a 'cp --reflink=never' (never works for --sparse), either silently or with a warning/note.
For a cow VM imagefile, the only thing I do and want w.r.t. cp is reflink=always, so I also vote for auto on by default.
If you want to 'defrag' a VM imagefile, using cat or dd and enough RAM does a better and faster job than cp or btrfs manual defrag.
Quoted 9 lines
And the cost on non-btrfs non-unmerged-xfs is a single syscall per file, that's utterly negligible compared to actually copying the data.
--
An imaginary friend squared is a real enemy.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines · Austin S. Hemmelgarn
JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid it making reflinks.
I would have expected so, but at least in coreutils 8.23 the only valid options are "always" and "auto" (at least according to cp --help and the manpage).
Best,
-Nikolaus
Signature · 4 lines
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«