btrfs defrag questions
Hello everyone,
Question #1:
While doing defrag I got the following message:
# btrfs fi defrag -r /home ERROR: defrag failed on /home/user/.dropbox-dist/dropbox: Success total 1 failures
I feel that something went wrong, but the message is a bit misleading.
Provided that Dropbox is running in the system, does it mean that it cannot be defagmented?
Question #2:
Suppose that in above example /home/ftp is mounted as another btrfs array (not subvolume). Will 'btrfs fi defrag -r /home' defragment it (recursively) as well?
Signature · 2 lines
With best regards, Dmitry
(email ends up in gmail spamfolder)
Quoted 6 lines · Dmitry Katsubo
Hello everyone,
Question #1:
While doing defrag I got the following message:
Quoted 8 lines
# btrfs fi defrag -r /home ERROR: defrag failed on /home/user/.dropbox-dist/dropbox: Success total 1 failuresI feel that something went wrong, but the message is a bit misleading.
Provided that Dropbox is running in the system, does it mean that it cannot be defagmented?
I think it is a matter of newlines in btrfs-progs and/or stdout/stderr mixup.
You should run the command with -v and probably also with -f, so that it gets hopefully clearer what is wrong.
That it fails on dropbox is an error I think, but maybe known: Could be mount option is compress and that that causes trouble for defrag although that should not happen.
You can defrag just 1 file, so maybe you could try to make a reproducible case. What kernel?
What btrfs-progs?
Quoted 5 lines
Question #2:
Suppose that in above example
/home/ftpis mounted as another btrfs array (not subvolume). Will 'btrfs fi defrag -r /home' defragment it (recursively) as well?
I dont know, I dont think so, but you can simply try.
Quoted 14 lines · Henk Slager
(email ends up in gmail spamfolder)
Quoted 12 lines · Dmitry Katsubo
Hello everyone,
Question #1:
While doing defrag I got the following message:
# btrfs fi defrag -r /home ERROR: defrag failed on /home/user/.dropbox-dist/dropbox: Success total 1 failuresI feel that something went wrong, but the message is a bit misleading.
Quoted 7 lines
Quoted 2 lines
Provided that Dropbox is running in the system, does it mean that it cannot be defagmented?
I think it is a matter of newlines in btrfs-progs and/or stdout/stderr mixup.
You should run the command with -v and probably also with -f, so that it gets hopefully clearer what is wrong.
Running with "-v -f" (or just "-v") result the same output:
.../home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/select.so/home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/grp.so/home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/posixffi.libc._posixffi_libcERROR: defrag failed on /home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/dropbox: Success .so/home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/_functools.so/home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/dropbox/home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/_csv.so
...
This is not a matter of newlines:
$ grep -rnH 'defrag failed' btrfs-progs
btrfs-progs/cmds-filesystem.c:1021: error("defrag failed on %s: %s", fpath, strerror(e));
btrfs-progs/cmds-filesystem.c:1161: error("defrag failed on %s: %s", argv[i], strerror(e));Quoted 3 lines
That it fails on dropbox is an error I think, but maybe known: Could be mount option is compress and that that causes trouble for defrag although that should not happen.
True, compression is enabled.
Quoted 1 line
You can defrag just 1 file, so maybe you could try to make a reproducible case.
When I run it on one file, it works as expected:
# btrfs fi defrag -r -v /home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/dropbox ERROR: cannot open /home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/dropbox: Text file busy
Quoted 2 lines
What kernel?
What btrfs-progs?
kernel v4.4.6
btrfs-tools v4.5.2
Quoted 7 lines
Quoted 5 lines
Question #2:
Suppose that in above example
/home/ftpis mounted as another btrfs array (not subvolume). Will 'btrfs fi defrag -r /home' defragment it (recursively) as well?I dont know, I dont think so, but you can simply try.
Many thanks, now I see how can I check this. Unfortunately it does not descend into submounted directories.
Signature · 2 lines
With best regards, Dmitry
Quoted 41 lines · Dmitry Katsubo
Quoted 14 lines · Henk Slager
(email ends up in gmail spamfolder)
Quoted 12 lines · Dmitry Katsubo
Hello everyone,
Question #1:
While doing defrag I got the following message:
# btrfs fi defrag -r /home ERROR: defrag failed on /home/user/.dropbox-dist/dropbox: Success total 1 failuresI feel that something went wrong, but the message is a bit misleading.
Quoted 7 lines
Quoted 2 lines
Provided that Dropbox is running in the system, does it mean that it cannot be defagmented?
I think it is a matter of newlines in btrfs-progs and/or stdout/stderr mixup.
You should run the command with -v and probably also with -f, so that it gets hopefully clearer what is wrong.
Running with "-v -f" (or just "-v") result the same output:
...
/home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/select.so/home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/grp.so/home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/posixffi.libc._posixffi_libcERROR: defrag failed on/home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/dropbox: Success .so/home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/_functools.so/home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/dropbox/home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/_csv.so
...This is not a matter of newlines:
$ grep -rnH 'defrag failed' btrfs-progs btrfs-progs/cmds-filesystem.c:1021: error("defrag failed on %s: %s", fpath, strerror(e)); btrfs-progs/cmds-filesystem.c:1161: error("defrag failed on %s: %s", argv[i], strerror(e));
Quoted 5 lines
Quoted 3 lines
That it fails on dropbox is an error I think, but maybe known: Could be mount option is compress and that that causes trouble for defrag although that should not happen.
True, compression is enabled.
The reason I mentioned compression is that this adds another layer between the disksectors and the (4K) pages in RAM. My thinking is that if defrag is done by the kernel (which is the case AFAIK), it should in theory be possible to hook at some layer, so that in the case in this email defrag should be able to work.
The big question is, if it is worth the (probably complex) implementation effort, independent whether you consider this bug or a feature enhancement.
My experience with manual defrag (so initiated by btrfs-progs) is that it can take long time and the result can be worse than a copy-mv sequence (real copy, no --reflink, so done with cat or dd or rsync) and is also way faster. This is for files in GiB range and with snapshots existing (no compression). With no compression and no snapshots, it might be different.
Quoted 31 lines
Quoted 1 line
You can defrag just 1 file, so maybe you could try to make a reproducible case.
When I run it on one file, it works as expected:
# btrfs fi defrag -r -v /home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/dropbox ERROR: cannot open /home/user/.dropbox-dist/dropbox-lnx.x86-5.4.24/dropbox: Text file busyQuoted 2 lines
What kernel?
What btrfs-progs?kernel v4.4.6
btrfs-tools v4.5.2Quoted 7 lines
Quoted 5 lines
Question #2:
Suppose that in above example
/home/ftpis mounted as another btrfs array (not subvolume). Will 'btrfs fi defrag -r /home' defragment it (recursively) as well?I dont know, I dont think so, but you can simply try.
Many thanks, now I see how can I check this. Unfortunately it does not descend into submounted directories.
--
With best regards,
Dmitry
--
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
Am Fri, 1 Jul 2016 22:14:00 +0200
schrieb Dmitry Katsubo <[email protected]>:
Quoted 6 lines
Hello everyone,
Question #1:
While doing defrag I got the following message:
Quoted 8 lines
# btrfs fi defrag -r /home ERROR: defrag failed on /home/user/.dropbox-dist/dropbox: Success total 1 failuresI feel that something went wrong, but the message is a bit misleading.
Provided that Dropbox is running in the system, does it mean that it cannot be defagmented?
That is probably true. Files that are mapped into memory (like running executables) cannot be changed on disk. You could make a copy of that file, remove the original, and rename the new into place. As long as the executable is running it will stay on disk but you can now defragment the file and next time dropbox is started it will use the new one.
Quoted 5 lines
Question #2:
Suppose that in above example
/home/ftpis mounted as another btrfs array (not subvolume). Will 'btrfs fi defrag -r /home' defragment it (recursively) as well?
Yes, last time I tried the command crossed file system boundaries. It will simply report ioctl errors if it operates on incompatible files and continue its way.
Signature · 4 lines
Regards, Kai Replies to list-only preferred.
Quoted 18 lines · Kai Krakow
Am Fri, 1 Jul 2016 22:14:00 +0200
schrieb Dmitry Katsubo <[email protected]>:Quoted 6 lines
Hello everyone,
Question #1:
While doing defrag I got the following message:
Quoted 8 lines
# btrfs fi defrag -r /home ERROR: defrag failed on /home/user/.dropbox-dist/dropbox: Success total 1 failuresI feel that something went wrong, but the message is a bit misleading.
Provided that Dropbox is running in the system, does it mean that it cannot be defagmented?
Quoted 6 lines
That is probably true. Files that are mapped into memory (like running executables) cannot be changed on disk. You could make a copy of that file, remove the original, and rename the new into place. As long as the executable is running it will stay on disk but you can now defragment the file and next time dropbox is started it will use the new one.
I get:
ERROR: cannot open ./dropbox: Text file busy
when I run:
btrfs fi defrag -v ./dropbox
This is with kernel 4.6.2 and progs 4.6.1, dropbox running and mount option compress=lzo
Quoted 10 lines · Henk Slager
Quoted 9 lines
Quoted 2 lines
Provided that Dropbox is running in the system, does it mean that it cannot be defagmented?
That is probably true. Files that are mapped into memory (like running executables) cannot be changed on disk. You could make a copy of that file, remove the original, and rename the new into place. As long as the executable is running it will stay on disk but you can now defragment the file and next time dropbox is started it will use the new one.
Quoted 8 lines
I get:
ERROR: cannot open ./dropbox: Text file busywhen I run:
btrfs fi defrag -v ./dropboxThis is with kernel 4.6.2 and progs 4.6.1, dropbox running and mount option compress=lzo
This is the same thing as with dedupe: the kernel requires you to have the file opened for writing despite there being no direct reasons for this. Defragging is not a write operation in POSIX sense: it doesn't alter the file's contents in any way.
I think it'd be good to relax this requirement to check whether the user _could_ open the file for writing (ie, cap or w permissions).
Signature · 1 line
An imaginary friend squared is a real enemy.
Am Sun, 3 Jul 2016 23:30:20 +0200
schrieb Adam Borowski <[email protected]>:
Quoted 19 lines · Henk Slager
[...]
Quoted 8 lines
Quoted 7 lines
That is probably true. Files that are mapped into memory (like running executables) cannot be changed on disk. You could make a copy of that file, remove the original, and rename the new into place. As long as the executable is running it will stay on disk but you can now defragment the file and next time dropbox is started it will use the new one.
Quoted 8 lines
I get:
ERROR: cannot open ./dropbox: Text file busywhen I run:
btrfs fi defrag -v ./dropboxThis is with kernel 4.6.2 and progs 4.6.1, dropbox running and mount option compress=lzo
Quoted 7 lines
This is the same thing as with dedupe: the kernel requires you to have the file opened for writing despite there being no direct reasons for this. Defragging is not a write operation in POSIX sense:
it doesn't alter the file's contents in any way.I think it'd be good to relax this requirement to check whether the user _could_ open the file for writing (ie, cap or w permissions).
I don't think that works because the file is mapped into memory while it is executed. The kernel doesn't actively load an executable. It is just mapped into memory and acts like a mini swap file: Blocks are paged into RAM as soon as the CPU encounters them. Executing a file involves page faults. And this is why you cannot rearrange it on disk:
The kernel holds a lock while the file's contents are mapped, it needs consistent 1:1 block mapping determined at time of mapping the file.
You can however manipulate the file name. If you move the file, then _copy_ it back into place, then remove the old file, the contents become orphan. The contents will be unlinked from storage if the file mapping is closed. If your PC is rebooted while the orphan exists, the file system will do an orphan cleanup at reboot (you will see such messages in dmesg then). The fact that you made a copy and moved it in place of the original filename, however, allows you to now modify the file contents - as this copy is not mapped. That won't touch the original orphan contents. I think this should also be possible with a reflink copy (cp -b) but I'm not sure.
You simply cannot change on-disk layout of mapped files. In addition, you cannot write to executables mapped into memory - it would destroy consistency of what the memory manager swapped into RAM and what is on disk. The error message here is "text file busy". In the context of executables, "text" is the program text - read: the binary instructions for the CPU. It has nothing to do with an ordinary text file humans can read (the common meaning is just "read" as in "CPUs can read" and "humans can read").
So in other words: There is a direct reason, and you actually change contents on disk from kernel perspective just because their layout is changed. Think of it like this: If you defrag the file, it's contents do not change, yes, just the layout. The blocks are moved somewhere else. Next time, the kernel tries to page a block from disk of the previously learned mapping (which is now invalid), the block may have changed because you added new files to the disk. Thus, the content of the block has changed, the executable would crash. I think this has nothing to do with POSIX - the Linux kernel isn't even pure POSIX conform (it just tries to stay as close as possible). This is just how running executables works and this needs protection against tampering or other attacks.
Other OSes like Windows act in the same way (executables are mapped into memory, not loaded). But Windows/NTFS doesn't support the concept of orphans (at least not that I know of) which makes mapped executables (DLL, EXE) immutable while they are mapped. One reason why Windows needs a reboot for everything and Unix OSes don't.
If OSes would load todays executables program text into memory (thus making a complete copy of it into RAM), like good old DOS did, they would become pretty slow. Binary executables are paged into RAM on demand.
Signature · 4 lines
Regards, Kai Replies to list-only preferred.
Am Mon, 4 Jul 2016 23:16:50 +0200
schrieb Kai Krakow <[email protected]>:
Quoted 71 lines
Am Sun, 3 Jul 2016 23:30:20 +0200
schrieb Adam Borowski <[email protected]>:Quoted 2 lines · Henk Slager
[...]
[...]
Quoted 10 lines
Quoted 9 lines
I get:
ERROR: cannot open ./dropbox: Text file busywhen I run:
btrfs fi defrag -v ./dropboxThis is with kernel 4.6.2 and progs 4.6.1, dropbox running and mount option compress=lzo
Quoted 7 lines
This is the same thing as with dedupe: the kernel requires you to have the file opened for writing despite there being no direct reasons for this. Defragging is not a write operation in POSIX
sense: it doesn't alter the file's contents in any way.I think it'd be good to relax this requirement to check whether the user _could_ open the file for writing (ie, cap or w permissions).
I don't think that works because the file is mapped into memory while it is executed. The kernel doesn't actively load an executable. It is just mapped into memory and acts like a mini swap file: Blocks are paged into RAM as soon as the CPU encounters them. Executing a file involves page faults. And this is why you cannot rearrange it on disk:
The kernel holds a lock while the file's contents are mapped, it needs consistent 1:1 block mapping determined at time of mapping the file.You can however manipulate the file name. If you move the file, then _copy_ it back into place, then remove the old file, the contents become orphan. The contents will be unlinked from storage if the file mapping is closed. If your PC is rebooted while the orphan exists, the file system will do an orphan cleanup at reboot (you will see such messages in dmesg then). The fact that you made a copy and moved it in place of the original filename, however, allows you to now modify the file contents - as this copy is not mapped. That won't touch the original orphan contents. I think this should also be possible with a reflink copy (cp -b) but I'm not sure.
You simply cannot change on-disk layout of mapped files. In addition, you cannot write to executables mapped into memory - it would destroy consistency of what the memory manager swapped into RAM and what is on disk. The error message here is "text file busy". In the context of executables, "text" is the program text - read: the binary instructions for the CPU. It has nothing to do with an ordinary text file humans can read (the common meaning is just "read" as in "CPUs can read" and "humans can read").
So in other words: There is a direct reason, and you actually change contents on disk from kernel perspective just because their layout is changed. Think of it like this: If you defrag the file, it's contents do not change, yes, just the layout. The blocks are moved somewhere else. Next time, the kernel tries to page a block from disk of the previously learned mapping (which is now invalid), the block may have changed because you added new files to the disk. Thus, the content of the block has changed, the executable would crash. I think this has nothing to do with POSIX - the Linux kernel isn't even pure POSIX conform (it just tries to stay as close as possible). This is just how running executables works and this needs protection against tampering or other attacks.
Other OSes like Windows act in the same way (executables are mapped into memory, not loaded). But Windows/NTFS doesn't support the concept of orphans (at least not that I know of) which makes mapped executables (DLL, EXE) immutable while they are mapped. One reason why Windows needs a reboot for everything and Unix OSes don't.
Quoted 7 lines
If OSes would load todays executables program text into memory (thus making a complete copy of it into RAM), like good old DOS did, they would become pretty slow. Binary executables are paged into RAM on demand.
BTW: This is why prelinking improves application startup times... Usually, at start of a binary, the dynamic linker will adjust jump addresses throughout the whole binary involving a lot of page faults. Prelinking largely solves this by doing runtime linking in advance so the runtime linker's modification to the binary are reduced to a minimum. Page faults are reduced and application startup will be more instant. I think this even reduces memory pressure as the pages can simply be discarded because they are not modified in memory during startup. This, however, involves predeterming a common memory layout for all binaries sharing the same libraries - which is quite expensive and works better on 64bit systems. This is why prelinking takes a long time, has to be updated when you update packages, and can even fail if address space is too small (which hits you early on 32bit).
The fact that prelinking sets address space layout in advance may also reduce system security because it will no longer be random at time the dynamic linker runs - but this is probably not a very strong point against prelinking on desktop systems. Prelinking is usually redone on a daily basis by a cronjob.
Signature · 4 lines
Regards, Kai Replies to list-only preferred.