[opensuse] What fills root if not snapshots
Hi all, This Asus laptop (with TW and KDE) was not used for ten days. Yesterday evening I switched it on and saw I have >800 updates. I tried tio install them with zypper dup. I failed, because root got full. This was with 4.18.0 kernel. I managed to boot into 4.17.14 kernel (got some complaints, but none showstopper) and manually remove all downloaded rpm packages from /var/cache/zypp/packages with mc. Dolphin did not start in superuser mode. All these deleted and having only the 0 and 1 snapshots, I have less than 600 M in root from 40 G. And I have no idea where is the rest of the space? Can I get any help? Albert
03.09.2018 19:40, Albert Oszkó пишет:
Hi all,
This Asus laptop (with TW and KDE) was not used for ten days. Yesterday evening I switched it on and saw I have >800 updates. I tried tio install them with zypper dup. I failed, because root got full. This was with 4.18.0 kernel. I managed to boot into 4.17.14 kernel (got some complaints, but none showstopper) and manually remove all downloaded rpm packages from /var/cache/zypp/packages with mc. Dolphin did not start in superuser mode. All these deleted and having only the 0 and 1 snapshots, I have less than 600 M in root from 40 G. And I have no idea where is the rest of the space?
Start with showing output of btrfs fi us / btrfs su li / btrfs qgroup show / -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
2018-09-03 19:18 keltezéssel, Andrei Borzenkov írta:
03.09.2018 19:40, Albert Oszkó пишет:
Hi all,
This Asus laptop (with TW and KDE) was not used for ten days. Yesterday evening I switched it on and saw I have >800 updates. I tried tio install them with zypper dup. I failed, because root got full. This was with 4.18.0 kernel. I managed to boot into 4.17.14 kernel (got some complaints, but none showstopper) and manually remove all downloaded rpm packages from /var/cache/zypp/packages with mc. Dolphin did not start in superuser mode. All these deleted and having only the 0 and 1 snapshots, I have less than 600 M in root from 40 G. And I have no idea where is the rest of the space?
Start with showing output of
btrfs fi us / btrfs su li / btrfs qgroup show /
Here they are: linux-olq5:/home/berci # btrfs fi us / Overall: Device size: 40.00GiB Device allocated: 40.00GiB Device unallocated: 1.00MiB Device missing: 0.00B Used: 38.51GiB Free (estimated): 564.43MiB (min: 564.43MiB) Data ratio: 1.00 Metadata ratio: 2.00 Global reserve: 107.84MiB (used: 0.00B) Data,single: Size:36.44GiB, Used:35.89GiB /dev/sda3 36.44GiB Metadata,DUP: Size:1.75GiB, Used:1.31GiB /dev/sda3 3.50GiB System,DUP: Size:32.00MiB, Used:16.00KiB /dev/sda3 64.00MiB Unallocated: /dev/sda3 1.00MiB linux-olq5:/home/berci # btrfs su li / ID 257 gen 171200 top level 5 path @ ID 258 gen 512167 top level 257 path @/.snapshots ID 259 gen 512383 top level 258 path @/.snapshots/1/snapshot ID 260 gen 184118 top level 257 path @/boot/grub2/i386-pc ID 261 gen 440004 top level 257 path @/boot/grub2/x86_64-efi ID 262 gen 440407 top level 257 path @/opt ID 263 gen 440011 top level 257 path @/srv ID 264 gen 512383 top level 257 path @/tmp ID 265 gen 387780 top level 257 path @/usr/local ID 266 gen 512176 top level 257 path @/var/cache ID 267 gen 387725 top level 257 path @/var/crash ID 268 gen 168243 top level 257 path @/var/lib/libvirt/images ID 269 gen 171200 top level 257 path @/var/lib/machines ID 270 gen 168243 top level 257 path @/var/lib/mailman ID 271 gen 168243 top level 257 path @/var/lib/mariadb ID 272 gen 168243 top level 257 path @/var/lib/mysql ID 273 gen 168243 top level 257 path @/var/lib/named ID 274 gen 168243 top level 257 path @/var/lib/pgsql ID 275 gen 512383 top level 257 path @/var/log ID 276 gen 387725 top level 257 path @/var/opt ID 277 gen 512382 top level 257 path @/var/spool ID 278 gen 512383 top level 257 path @/var/tmp ID 754 gen 265167 top level 258 path @/.snapshots/64/snapshot ID 876 gen 336471 top level 258 path @/.snapshots/142/snapshot ID 883 gen 336471 top level 258 path @/.snapshots/148/snapshot ID 904 gen 341810 top level 258 path @/.snapshots/164/snapshot linux-olq5:/home/berci # btrfs qgroup show / qgroupid rfer excl -------- ---- ---- 0/5 16.00KiB 16.00KiB 0/257 16.00KiB 16.00KiB 0/258 48.00KiB 48.00KiB 0/259 11.14GiB 5.35GiB 0/260 16.00KiB 16.00KiB 0/261 3.38MiB 3.38MiB 0/262 546.26MiB 546.26MiB 0/263 60.00KiB 60.00KiB 0/264 423.66MiB 423.66MiB 0/265 16.00KiB 16.00KiB 0/266 182.83MiB 182.83MiB 0/267 16.00KiB 16.00KiB 0/268 16.00KiB 16.00KiB 0/269 16.00KiB 16.00KiB 0/270 16.00KiB 16.00KiB 0/271 16.00KiB 16.00KiB 0/272 16.00KiB 16.00KiB 0/273 16.00KiB 16.00KiB 0/274 16.00KiB 16.00KiB 0/275 1.18GiB 1.18GiB 0/276 16.00KiB 16.00KiB 0/277 68.00KiB 68.00KiB 0/278 188.95MiB 188.95MiB 0/403 0.00B 0.00B 0/439 0.00B 0.00B 0/580 3.17GiB 16.00EiB 0/581 413.15MiB 16.00EiB 0/638 0.00B 0.00B 0/754 10.40GiB 9.86GiB 0/876 10.96GiB 3.59GiB 0/883 11.00GiB 2.24GiB 0/904 10.92GiB 2.96GiB 1/0 29.23GiB 23.45GiB 255/269 16.00KiB 16.00KiB
03.09.2018 20:36, Albert Oszkó пишет:
2018-09-03 19:18 keltezéssel, Andrei Borzenkov írta:
03.09.2018 19:40, Albert Oszkó пишет:
Hi all,
This Asus laptop (with TW and KDE) was not used for ten days. Yesterday evening I switched it on and saw I have >800 updates. I tried tio install them with zypper dup. I failed, because root got full. This was with 4.18.0 kernel. I managed to boot into 4.17.14 kernel (got some complaints, but none showstopper) and manually remove all downloaded rpm packages from /var/cache/zypp/packages with mc. Dolphin did not start in superuser mode. All these deleted and having only the 0 and 1 snapshots, I have less than 600 M in root from 40 G. And I have no idea where is the rest of the space?
Start with showing output of
btrfs fi us / btrfs su li / btrfs qgroup show /
Here they are:
linux-olq5:/home/berci # btrfs fi us / Overall: Device size: 40.00GiB Device allocated: 40.00GiB Device unallocated: 1.00MiB Device missing: 0.00B Used: 38.51GiB Free (estimated): 564.43MiB (min: 564.43MiB) Data ratio: 1.00 Metadata ratio: 2.00 Global reserve: 107.84MiB (used: 0.00B)
Data,single: Size:36.44GiB, Used:35.89GiB /dev/sda3 36.44GiB
Metadata,DUP: Size:1.75GiB, Used:1.31GiB /dev/sda3 3.50GiB
System,DUP: Size:32.00MiB, Used:16.00KiB /dev/sda3 64.00MiB
Unallocated: /dev/sda3 1.00MiB linux-olq5:/home/berci # btrfs su li / ID 257 gen 171200 top level 5 path @ ID 258 gen 512167 top level 257 path @/.snapshots ID 259 gen 512383 top level 258 path @/.snapshots/1/snapshot
I presume this is your "1" snapshot. What btrfs su get / grep ' / ' /proc/self/mounts say?
ID 260 gen 184118 top level 257 path @/boot/grub2/i386-pc ID 261 gen 440004 top level 257 path @/boot/grub2/x86_64-efi ID 262 gen 440407 top level 257 path @/opt ID 263 gen 440011 top level 257 path @/srv ID 264 gen 512383 top level 257 path @/tmp ID 265 gen 387780 top level 257 path @/usr/local ID 266 gen 512176 top level 257 path @/var/cache ID 267 gen 387725 top level 257 path @/var/crash ID 268 gen 168243 top level 257 path @/var/lib/libvirt/images ID 269 gen 171200 top level 257 path @/var/lib/machines ID 270 gen 168243 top level 257 path @/var/lib/mailman ID 271 gen 168243 top level 257 path @/var/lib/mariadb ID 272 gen 168243 top level 257 path @/var/lib/mysql ID 273 gen 168243 top level 257 path @/var/lib/named ID 274 gen 168243 top level 257 path @/var/lib/pgsql ID 275 gen 512383 top level 257 path @/var/log ID 276 gen 387725 top level 257 path @/var/opt ID 277 gen 512382 top level 257 path @/var/spool ID 278 gen 512383 top level 257 path @/var/tmp ID 754 gen 265167 top level 258 path @/.snapshots/64/snapshot ID 876 gen 336471 top level 258 path @/.snapshots/142/snapshot ID 883 gen 336471 top level 258 path @/.snapshots/148/snapshot ID 904 gen 341810 top level 258 path @/.snapshots/164/snapshot
You do have older snapshots even if they are "lost" for snapper. What snapper list says?
linux-olq5:/home/berci # btrfs qgroup show / qgroupid rfer excl -------- ---- ---- 0/5 16.00KiB 16.00KiB 0/257 16.00KiB 16.00KiB 0/258 48.00KiB 48.00KiB 0/259 11.14GiB 5.35GiB
Your (likely) current root consumes 11GiB
0/260 16.00KiB 16.00KiB 0/261 3.38MiB 3.38MiB 0/262 546.26MiB 546.26MiB 0/263 60.00KiB 60.00KiB 0/264 423.66MiB 423.66MiB 0/265 16.00KiB 16.00KiB 0/266 182.83MiB 182.83MiB 0/267 16.00KiB 16.00KiB 0/268 16.00KiB 16.00KiB 0/269 16.00KiB 16.00KiB 0/270 16.00KiB 16.00KiB 0/271 16.00KiB 16.00KiB 0/272 16.00KiB 16.00KiB 0/273 16.00KiB 16.00KiB 0/274 16.00KiB 16.00KiB 0/275 1.18GiB 1.18GiB 0/276 16.00KiB 16.00KiB 0/277 68.00KiB 68.00KiB 0/278 188.95MiB 188.95MiB
Starting from here ...
0/403 0.00B 0.00B 0/439 0.00B 0.00B 0/580 3.17GiB 16.00EiB 0/581 413.15MiB 16.00EiB 0/638 0.00B 0.00B
... to here there are stale entries. Those subvolumes no more exist. You should delete them btrfs qgroup destroy 0/403 / ... And then update quota information with btrfs quota rescan -w / then listing qgroup should be more close to reality
0/754 10.40GiB 9.86GiB 0/876 10.96GiB 3.59GiB 0/883 11.00GiB 2.24GiB 0/904 10.92GiB 2.96GiB 1/0 29.23GiB 23.45GiB
And those "lost" snapshots consume 23.45GiB together.
255/269 16.00KiB 16.00KiB
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
2018-09-03 19:51 keltezéssel, Andrei Borzenkov írta:
03.09.2018 20:36, Albert Oszkó пишет:
2018-09-03 19:18 keltezéssel, Andrei Borzenkov írta:
03.09.2018 19:40, Albert Oszkó пишет:
Hi all,
This Asus laptop (with TW and KDE) was not used for ten days. Yesterday evening I switched it on and saw I have >800 updates. I tried tio install them with zypper dup. I failed, because root got full. This was with 4.18.0 kernel. I managed to boot into 4.17.14 kernel (got some complaints, but none showstopper) and manually remove all downloaded rpm packages from /var/cache/zypp/packages with mc. Dolphin did not start in superuser mode. All these deleted and having only the 0 and 1 snapshots, I have less than 600 M in root from 40 G. And I have no idea where is the rest of the space?
Start with showing output of
btrfs fi us / btrfs su li / btrfs qgroup show /
Here they are:
linux-olq5:/home/berci # btrfs fi us / Overall: Device size: 40.00GiB Device allocated: 40.00GiB Device unallocated: 1.00MiB Device missing: 0.00B Used: 38.51GiB Free (estimated): 564.43MiB (min: 564.43MiB) Data ratio: 1.00 Metadata ratio: 2.00 Global reserve: 107.84MiB (used: 0.00B)
Data,single: Size:36.44GiB, Used:35.89GiB /dev/sda3 36.44GiB
Metadata,DUP: Size:1.75GiB, Used:1.31GiB /dev/sda3 3.50GiB
System,DUP: Size:32.00MiB, Used:16.00KiB /dev/sda3 64.00MiB
Unallocated: /dev/sda3 1.00MiB linux-olq5:/home/berci # btrfs su li / ID 257 gen 171200 top level 5 path @ ID 258 gen 512167 top level 257 path @/.snapshots ID 259 gen 512383 top level 258 path @/.snapshots/1/snapshot I presume this is your "1" snapshot. What
btrfs su get / grep ' / ' /proc/self/mounts
say?
ID 260 gen 184118 top level 257 path @/boot/grub2/i386-pc ID 261 gen 440004 top level 257 path @/boot/grub2/x86_64-efi ID 262 gen 440407 top level 257 path @/opt ID 263 gen 440011 top level 257 path @/srv ID 264 gen 512383 top level 257 path @/tmp ID 265 gen 387780 top level 257 path @/usr/local ID 266 gen 512176 top level 257 path @/var/cache ID 267 gen 387725 top level 257 path @/var/crash ID 268 gen 168243 top level 257 path @/var/lib/libvirt/images ID 269 gen 171200 top level 257 path @/var/lib/machines ID 270 gen 168243 top level 257 path @/var/lib/mailman ID 271 gen 168243 top level 257 path @/var/lib/mariadb ID 272 gen 168243 top level 257 path @/var/lib/mysql ID 273 gen 168243 top level 257 path @/var/lib/named ID 274 gen 168243 top level 257 path @/var/lib/pgsql ID 275 gen 512383 top level 257 path @/var/log ID 276 gen 387725 top level 257 path @/var/opt ID 277 gen 512382 top level 257 path @/var/spool ID 278 gen 512383 top level 257 path @/var/tmp ID 754 gen 265167 top level 258 path @/.snapshots/64/snapshot ID 876 gen 336471 top level 258 path @/.snapshots/142/snapshot ID 883 gen 336471 top level 258 path @/.snapshots/148/snapshot ID 904 gen 341810 top level 258 path @/.snapshots/164/snapshot You do have older snapshots even if they are "lost" for snapper. What
snapper list
says?
linux-olq5:/home/berci # btrfs qgroup show / qgroupid rfer excl -------- ---- ---- 0/5 16.00KiB 16.00KiB 0/257 16.00KiB 16.00KiB 0/258 48.00KiB 48.00KiB 0/259 11.14GiB 5.35GiB Your (likely) current root consumes 11GiB
0/260 16.00KiB 16.00KiB 0/261 3.38MiB 3.38MiB 0/262 546.26MiB 546.26MiB 0/263 60.00KiB 60.00KiB 0/264 423.66MiB 423.66MiB 0/265 16.00KiB 16.00KiB 0/266 182.83MiB 182.83MiB 0/267 16.00KiB 16.00KiB 0/268 16.00KiB 16.00KiB 0/269 16.00KiB 16.00KiB 0/270 16.00KiB 16.00KiB 0/271 16.00KiB 16.00KiB 0/272 16.00KiB 16.00KiB 0/273 16.00KiB 16.00KiB 0/274 16.00KiB 16.00KiB 0/275 1.18GiB 1.18GiB 0/276 16.00KiB 16.00KiB 0/277 68.00KiB 68.00KiB 0/278 188.95MiB 188.95MiB Starting from here ...
0/403 0.00B 0.00B 0/439 0.00B 0.00B 0/580 3.17GiB 16.00EiB 0/581 413.15MiB 16.00EiB 0/638 0.00B 0.00B ... to here there are stale entries. Those subvolumes no more exist. You should delete them
btrfs qgroup destroy 0/403 / ...
And then update quota information with
btrfs quota rescan -w /
then listing qgroup should be more close to reality
0/754 10.40GiB 9.86GiB 0/876 10.96GiB 3.59GiB 0/883 11.00GiB 2.24GiB 0/904 10.92GiB 2.96GiB 1/0 29.23GiB 23.45GiB And those "lost" snapshots consume 23.45GiB together.
255/269 16.00KiB 16.00KiB
Answers to your latest questions: linux-olq5:~ # btrfs su get / ID 259 gen 512468 top level 258 path @/.snapshots/1/snapshot linux-olq5:~ # grep ' / ' /proc/self/mounts /dev/sda3 / btrfs rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot 0 0 linux-olq5:~ # snapper list Type | # | Pre # | Date | User | Cleanup | Description | Userdata -------+---+-------+--------------------------+------+---------+-----------------------+--------- single | 0 | | | root | | current | single | 1 | | Fri Sep 22 21:19:30 2017 | root | | first root filesystem |
2018-09-03 19:51 keltezéssel, Andrei Borzenkov írta:
03.09.2018 20:36, Albert Oszkó пишет:
2018-09-03 19:18 keltezéssel, Andrei Borzenkov írta:
03.09.2018 19:40, Albert Oszkó пишет:
Hi all,
This Asus laptop (with TW and KDE) was not used for ten days. Yesterday evening I switched it on and saw I have >800 updates. I tried tio install them with zypper dup. I failed, because root got full. This was with 4.18.0 kernel. I managed to boot into 4.17.14 kernel (got some complaints, but none showstopper) and manually remove all downloaded rpm packages from /var/cache/zypp/packages with mc. Dolphin did not start in superuser mode. All these deleted and having only the 0 and 1 snapshots, I have less than 600 M in root from 40 G. And I have no idea where is the rest of the space?
Start with showing output of
btrfs fi us / btrfs su li / btrfs qgroup show /
Here they are:
linux-olq5:/home/berci # btrfs fi us / Overall: Device size: 40.00GiB Device allocated: 40.00GiB Device unallocated: 1.00MiB Device missing: 0.00B Used: 38.51GiB Free (estimated): 564.43MiB (min: 564.43MiB) Data ratio: 1.00 Metadata ratio: 2.00 Global reserve: 107.84MiB (used: 0.00B)
Data,single: Size:36.44GiB, Used:35.89GiB /dev/sda3 36.44GiB
Metadata,DUP: Size:1.75GiB, Used:1.31GiB /dev/sda3 3.50GiB
System,DUP: Size:32.00MiB, Used:16.00KiB /dev/sda3 64.00MiB
Unallocated: /dev/sda3 1.00MiB linux-olq5:/home/berci # btrfs su li / ID 257 gen 171200 top level 5 path @ ID 258 gen 512167 top level 257 path @/.snapshots ID 259 gen 512383 top level 258 path @/.snapshots/1/snapshot I presume this is your "1" snapshot. What
btrfs su get / grep ' / ' /proc/self/mounts
say?
ID 260 gen 184118 top level 257 path @/boot/grub2/i386-pc ID 261 gen 440004 top level 257 path @/boot/grub2/x86_64-efi ID 262 gen 440407 top level 257 path @/opt ID 263 gen 440011 top level 257 path @/srv ID 264 gen 512383 top level 257 path @/tmp ID 265 gen 387780 top level 257 path @/usr/local ID 266 gen 512176 top level 257 path @/var/cache ID 267 gen 387725 top level 257 path @/var/crash ID 268 gen 168243 top level 257 path @/var/lib/libvirt/images ID 269 gen 171200 top level 257 path @/var/lib/machines ID 270 gen 168243 top level 257 path @/var/lib/mailman ID 271 gen 168243 top level 257 path @/var/lib/mariadb ID 272 gen 168243 top level 257 path @/var/lib/mysql ID 273 gen 168243 top level 257 path @/var/lib/named ID 274 gen 168243 top level 257 path @/var/lib/pgsql ID 275 gen 512383 top level 257 path @/var/log ID 276 gen 387725 top level 257 path @/var/opt ID 277 gen 512382 top level 257 path @/var/spool ID 278 gen 512383 top level 257 path @/var/tmp ID 754 gen 265167 top level 258 path @/.snapshots/64/snapshot ID 876 gen 336471 top level 258 path @/.snapshots/142/snapshot ID 883 gen 336471 top level 258 path @/.snapshots/148/snapshot ID 904 gen 341810 top level 258 path @/.snapshots/164/snapshot You do have older snapshots even if they are "lost" for snapper. What
snapper list
says?
linux-olq5:/home/berci # btrfs qgroup show / qgroupid rfer excl -------- ---- ---- 0/5 16.00KiB 16.00KiB 0/257 16.00KiB 16.00KiB 0/258 48.00KiB 48.00KiB 0/259 11.14GiB 5.35GiB Your (likely) current root consumes 11GiB
0/260 16.00KiB 16.00KiB 0/261 3.38MiB 3.38MiB 0/262 546.26MiB 546.26MiB 0/263 60.00KiB 60.00KiB 0/264 423.66MiB 423.66MiB 0/265 16.00KiB 16.00KiB 0/266 182.83MiB 182.83MiB 0/267 16.00KiB 16.00KiB 0/268 16.00KiB 16.00KiB 0/269 16.00KiB 16.00KiB 0/270 16.00KiB 16.00KiB 0/271 16.00KiB 16.00KiB 0/272 16.00KiB 16.00KiB 0/273 16.00KiB 16.00KiB 0/274 16.00KiB 16.00KiB 0/275 1.18GiB 1.18GiB 0/276 16.00KiB 16.00KiB 0/277 68.00KiB 68.00KiB 0/278 188.95MiB 188.95MiB Starting from here ...
0/403 0.00B 0.00B 0/439 0.00B 0.00B 0/580 3.17GiB 16.00EiB 0/581 413.15MiB 16.00EiB 0/638 0.00B 0.00B ... to here there are stale entries. Those subvolumes no more exist. You should delete them
btrfs qgroup destroy 0/403 / ...
And then update quota information with
btrfs quota rescan -w /
then listing qgroup should be more close to reality
0/754 10.40GiB 9.86GiB 0/876 10.96GiB 3.59GiB 0/883 11.00GiB 2.24GiB 0/904 10.92GiB 2.96GiB 1/0 29.23GiB 23.45GiB And those "lost" snapshots consume 23.45GiB together.
255/269 16.00KiB 16.00KiB
I did what you said: linux-olq5:~ # btrfs qgroup destroy 0/403 / linux-olq5:~ # btrfs quota rescan -w / quota rescan started linux-olq5:~ # btrfs qgroup show / qgroupid rfer excl -------- ---- ---- 0/5 16.00KiB 16.00KiB 0/257 16.00KiB 16.00KiB 0/258 48.00KiB 48.00KiB 0/259 11.12GiB 5.33GiB 0/260 16.00KiB 16.00KiB 0/261 3.38MiB 3.38MiB 0/262 546.26MiB 546.26MiB 0/263 60.00KiB 60.00KiB 0/264 423.63MiB 423.63MiB 0/265 16.00KiB 16.00KiB 0/266 182.83MiB 182.83MiB 0/267 16.00KiB 16.00KiB 0/268 16.00KiB 16.00KiB 0/269 16.00KiB 16.00KiB 0/270 16.00KiB 16.00KiB 0/271 16.00KiB 16.00KiB 0/272 16.00KiB 16.00KiB 0/273 16.00KiB 16.00KiB 0/274 16.00KiB 16.00KiB 0/275 1.19GiB 1.19GiB 0/276 16.00KiB 16.00KiB 0/277 68.00KiB 68.00KiB 0/278 190.15MiB 190.15MiB 0/439 0.00B 0.00B 0/580 3.17GiB 16.00EiB 0/581 413.15MiB 16.00EiB 0/638 0.00B 0.00B 0/754 10.40GiB 9.86GiB 0/876 10.96GiB 3.59GiB 0/883 11.00GiB 2.24GiB 0/904 10.92GiB 2.96GiB 1/0 29.23GiB 23.45GiB 255/269 16.00KiB 16.00KiB linux-olq5:~ # btrfs fi us / Overall: Device size: 40.00GiB Device allocated: 40.00GiB Device unallocated: 1.00MiB Device missing: 0.00B Used: 38.50GiB Free (estimated): 580.96MiB (min: 580.96MiB) Data ratio: 1.00 Metadata ratio: 2.00 Global reserve: 107.80MiB (used: 0.00B) Data,single: Size:36.44GiB, Used:35.87GiB /dev/sda3 36.44GiB Metadata,DUP: Size:1.75GiB, Used:1.31GiB /dev/sda3 3.50GiB System,DUP: Size:32.00MiB, Used:16.00KiB /dev/sda3 64.00MiB
03.09.2018 21:17, Albert Oszkó пишет: ...
0/278 188.95MiB 188.95MiB Starting from here ...
0/403 0.00B 0.00B 0/439 0.00B 0.00B 0/580 3.17GiB 16.00EiB 0/581 413.15MiB 16.00EiB 0/638 0.00B 0.00B ... to here there are stale entries. Those subvolumes no more exist. You should delete them
btrfs qgroup destroy 0/403 / ...
And then update quota information with
btrfs quota rescan -w /
then listing qgroup should be more close to reality
0/754 10.40GiB 9.86GiB 0/876 10.96GiB 3.59GiB 0/883 11.00GiB 2.24GiB 0/904 10.92GiB 2.96GiB 1/0 29.23GiB 23.45GiB And those "lost" snapshots consume 23.45GiB together.
255/269 16.00KiB 16.00KiB
I did what you said:
linux-olq5:~ # btrfs qgroup destroy 0/403 / linux-olq5:~ # btrfs quota rescan -w / quota rescan started
You miunderstand (twice actually). Qgroup is just accounting information. When quota is enabled, qgroup is automatically created for each subvolume but it is not destroyed when subvolume is deleted. Normally snapper should remove qgroup when it removes snapshot, but that apparently did not happen in your case. So suggestion was to simply clean up output to remove stale outdated information. And suggestion was to remove *all* of stale qgroups (those that do not have corresponding subvolume), not just one of them. But removing qgroup is not going to change anything in how much space is consumed and it was not intended to.
linux-olq5:~ # btrfs qgroup show / qgroupid rfer excl -------- ---- ---- ... 0/754 10.40GiB 9.86GiB 0/876 10.96GiB 3.59GiB 0/883 11.00GiB 2.24GiB 0/904 10.92GiB 2.96GiB 1/0 29.23GiB 23.45GiB
You still have those old snapshots that apparently lost their metadata and so are not "visible" to snapper.
ID 754 gen 265167 top level 258 path @/.snapshots/64/snapshot ID 876 gen 336471 top level 258 path @/.snapshots/142/snapshot ID 883 gen 336471 top level 258 path @/.snapshots/148/snapshot ID 904 gen 341810 top level 258 path @/.snapshots/164/snapshot
If you are absolutely sure you do not need them, you should remove them. This will gain you 23.45GiB. Also remove corresponding subdirectories under /.snapshots so as to not confuse snapper btrfs su del /.snapshots/64/snapshot rm -r /.snapshots/64 ... etc -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/03/2018 11:28 PM, Andrei Borzenkov wrote:
You miunderstand (twice actually). Qgroup is just accounting information. When quota is enabled, qgroup is automatically created for each subvolume but it is not destroyed when subvolume is deleted. Normally snapper should remove qgroup when it removes snapshot, but that apparently did not happen in your case.
Can you determine what likely caused the condition that lead to the metadata problem and snapper being unable to delete what it should? Is this a user invoked problem, or is this something that can just happen? I try and follow these threads as I evaluate whether I want to try btrfs, but in this case I can't even tell if this was a user issue or btrfs issue?? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I followed the advice here and regained 13 GB! Yeah! I was always fighting with updating TW as I was as 4.5GB free. Now I have 17GB free! While we are on the topic, what about snapshots 0 and 1? Mine are: Type | # | Pre # | Date | User | Cleanup | Description | Userdata -------+---+-------+----------------------------------+------+---------+-----------------------+--------- single | 0 | | | root | | current | single | 1 | | Wed 11 May 2016 09:07:17 PM CEST | root | | first root filesystem | I do not see myself ever going back the the original install (over 2 years ago). I think I would just reinstall if all went bad. Can one remove these snapshots? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
I followed the advice here and regained 13 GB! Yeah! I was always fighting with updating TW as I was as 4.5GB free. Now I have 17GB free!
So you did have 'lost snapshots', too? I didn't have any, but my / (when still only 40GB) was permanently close to full, too. So I wonder where they come from.
While we are on the topic, what about snapshots 0 and 1? Mine are:
Type | # | Pre # | Date | User | Cleanup | Description | Userdata -------+---+-------+----------------------------------+------+---------+-----------------------+--------- single | 0 | | | root | | current | single | 1 | | Wed 11 May 2016 09:07:17 PM CEST | root | | first root filesystem |
I do not see myself ever going back the the original install (over 2 years ago). I think I would just reinstall if all went bad. Can one remove these snapshots?
No. This *is* your actual running system (and the date indicates you never did a rollback so far, same as mine...). And zero - must be something like a link to the actual current one. Andrij for sure knows more :) I was more puzzled about the quota-related commands and cleanups. Those don't work for me, I only get "ERROR: can't list qgroups: quotas not enabled" Are they enabled by default on more recent installs? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Sep 4, 2018 at 2:03 PM Peter Suetterlin <pit@astro.su.se> wrote:
So you did have 'lost snapshots', too?
I had one lost snapshot. Removing it and then recalculating the quota made 13GB appear.
While we are on the topic, what about snapshots 0 and 1? Mine are:
Type | # | Pre # | Date | User | Cleanup | Description | Userdata -------+---+-------+----------------------------------+------+---------+-----------------------+--------- single | 0 | | | root | | current | single | 1 | | Wed 11 May 2016 09:07:17 PM CEST | root | | first root filesystem |
I do not see myself ever going back the the original install (over 2 years ago). I think I would just reinstall if all went bad. Can one remove these snapshots?
No. This *is* your actual running system (and the date indicates you never did a rollback so far, same as mine...). And zero - must be something like a link to the actual current one. Andrij for sure knows more :)
I would think that's the case. Not that I am going to try, but I wonder what might happen if one tried to remove them? Perhaps an error and it is not done? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Tue, Sep 4, 2018 at 2:03 PM Peter Suetterlin <pit@astro.su.se> wrote:
No. This *is* your actual running system (and the date indicates you never did a rollback so far, same as mine...). And zero - must be something like a link to the actual current one. Andrij for sure knows more :)
I would think that's the case. Not that I am going to try, but I wonder what might happen if one tried to remove them? Perhaps an error and it is not done?
IIRC you cannot, as it's acively mounted. But just look at woodstock:~ # btrfs subvolume get-default / ID 259 gen 897990 top level 258 path @/.snapshots/1/snapshot This is the subvolume that is (by default) mounted as your rootfs. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Does the 'professional' side, Suse Corporate support, see this sort of thing? Do these problems beset the industrial/commercial of BtrFS? If we were dealing with a pre-computer item that number of problems, problems with user management, then there would be serious questions about its design. Some things we deemed 'over-engineered'. In latter-day terms they weren't "user-friendly' as they needed a maintenance technician constantly at had. I'm sure some of us can recall a few classic IBM goofs of that nature. By contrast we have a few very boring file systems. We deem them 'out of support' because no-one wants to work on them. Or perhaps the designers got them right the first time. At one level it comes down to economics. With the over-egged system the vendor can charge the customers for ongoing support. The downside is that the vendor is better off it the support doesn't have to be carried out. And there's an even bigger downside if the customer has alternatives. IBM and Microsoft found that out. Both their solutions were similar: build systems that are *reliable* and *easy* for the customer to manage and maintain himself. Easy meaning that 'answers' to operational questions are obvious. The problems that IBM faced, that M$ faces, is cost & inflexibility. Right now, those are the great advantages of Linux. Well actually both are deceptive. There are hidden costs (like the need to have all this ongoing maintenance with the FS that Suse recommends (and note that RedHat doesn't). And, given what CompSci research has achieved over the last quarter century, the still-monolithic CPU-bound process model that Linux (and the other UNIX derivatives) perpetuates and propagates, isn't that flexible. But my main question is about whether or not the corporate side of Suse , its customers, have these problems with BtrFS as well. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 4 Sep 2018 at 15:40, Anton Aylward <opensuse@antonaylward.com> wrote:
Does the 'professional' side, Suse Corporate support, see this sort of thing? Do these problems beset the industrial/commercial of BtrFS?
If we were dealing with a pre-computer item that number of problems, problems with user management, then there would be serious questions about its design. Some things we deemed 'over-engineered'. In latter-day terms they weren't "user-friendly' as they needed a maintenance technician constantly at had. I'm sure some of us can recall a few classic IBM goofs of that nature.
By contrast we have a few very boring file systems. We deem them 'out of support' because no-one wants to work on them. Or perhaps the designers got them right the first time.
At one level it comes down to economics. With the over-egged system the vendor can charge the customers for ongoing support. The downside is that the vendor is better off it the support doesn't have to be carried out. And there's an even bigger downside if the customer has alternatives. IBM and Microsoft found that out.
Both their solutions were similar: build systems that are *reliable* and *easy* for the customer to manage and maintain himself.
Easy meaning that 'answers' to operational questions are obvious.
The problems that IBM faced, that M$ faces, is cost & inflexibility. Right now, those are the great advantages of Linux.
Well actually both are deceptive. There are hidden costs (like the need to have all this ongoing maintenance with the FS that Suse recommends (and note that RedHat doesn't).
And, given what CompSci research has achieved over the last quarter century, the still-monolithic CPU-bound process model that Linux (and the other UNIX derivatives) perpetuates and propagates, isn't that flexible.
But my main question is about whether or not the corporate side of Suse , its customers, have these problems with BtrFS as well.
Looking briefly at the thread it seems obvious to me that the user in question had a number of problems 1- an old installation with an old btrfs layout - modern btrfs installations have /var as a single subvolume. 2- a disk too small for their use - 40GB should be fine for many users, but that is just a default. After all anyone storing anything in /var, such as logs, is going to be 'robbing' space otherwise useful for snapshots 1. is a slight annoyance which anyone on any SUSE or openSUSE distribution before 15 needs to deal with, and does require attention to the paid to the individual contents of all the separate /var/* subvolumes. That said, the flattening of /var was mostly due to the needs of openSUSE Kubic not SUSE or regular openSUSE. 2. is a problem only for people who are not paying adequate attention to their own system, which would be atypical for SUSE customers. So, to answer your inflammatory question, corporate SUSE are very happy with their decision to use btrfs as their default root filesystem and their ongoing growth as a company can be at least partially attributed to the features available in SLE and CaaSP due to the extensive use of btrfs. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 4 Sep 2018 15:50:51 +0200 Richard Brown <RBrownCCB@opensuse.org> wrote:
Looking briefly at the thread it seems obvious to me that the user in question had a number of problems
1- an old installation with an old btrfs layout - modern btrfs installations have /var as a single subvolume.
I have an 'old' installation too - that is an installation that has been upgraded rather than freshly installed. Are you saying that is a 'problem'. If so, why does openSUSE offer it? Why does it not offer to convert it to the 'modern' installation?
2- a disk too small for their use - 40GB should be fine for many users, but that is just a default. After all anyone storing anything in /var, such as logs, is going to be 'robbing' space otherwise useful for snapshots
My root is 41G as well. openSUSE chose to put /var on that device, not me, and I use it to store logs and whatever else goes into /var because that's how openSUSE set it up. I have snapshots set up to be auto-deleted after one month for the regular stuff generated by YaST (which seems a little over-enthusiastic in their creation, if I'm honest) and I have about half my root partition free. I don't have any 'lost' snapshots; perhaps I'm lucky that I have no idea how they could occur.
1. is a slight annoyance which anyone on any SUSE or openSUSE distribution before 15 needs to deal with, and does require attention to the paid to the individual contents of all the separate /var/* subvolumes. That said, the flattening of /var was mostly due to the needs of openSUSE Kubic not SUSE or regular openSUSE.
2. is a problem only for people who are not paying adequate attention to their own system, which would be atypical for SUSE customers.
So, to answer your inflammatory question, corporate SUSE are very happy with their decision to use btrfs as their default root filesystem and their ongoing growth as a company can be at least partially attributed to the features available in SLE and CaaSP due to the extensive use of btrfs.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 4 Sep 2018 at 17:37, Dave Howorth <dave@howorth.org.uk> wrote:
On Tue, 4 Sep 2018 15:50:51 +0200 Richard Brown <RBrownCCB@opensuse.org> wrote:
Looking briefly at the thread it seems obvious to me that the user in question had a number of problems
1- an old installation with an old btrfs layout - modern btrfs installations have /var as a single subvolume.
I have an 'old' installation too - that is an installation that has been upgraded rather than freshly installed. Are you saying that is a 'problem'. If so, why does openSUSE offer it? Why does it not offer to convert it to the 'modern' installation?
Because we dont mess around with users data once it's written to disk. Users should be considered responsible for their own data, and we shouldn't go moving it around and putting it at risk as a result
2- a disk too small for their use - 40GB should be fine for many users, but that is just a default. After all anyone storing anything in /var, such as logs, is going to be 'robbing' space otherwise useful for snapshots
My root is 41G as well. openSUSE chose to put /var on that device, not me, and I use it to store logs and whatever else goes into /var because that's how openSUSE set it up.
openSUSE is not magic, and despite advances in artificial intelligence I believe it will still be a few decades before YaST achieves sentience and openSUSE can 'chose' anything for you. openSUSE's installation workflow shows you the partitioning clearly as part of its installation routine https://openqa.opensuse.org/tests/747376#step/partitioning/1 It provides 2 ways for you to alter such a proposal, either using the simple Guided Setup or the more complex Expert Partitioner You chose to accept what was presented to you. Whether it is right or wrong, all credit or scorn for that decision belongs to you, and not openSUSE. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-09-04 11:50 a.m., Richard Brown wrote:
openSUSE is not magic, and despite advances in artificial intelligence
Well ${OBSCENITY} to 'artificial intelligence' as an excuse. We've had AI as a moving target for over 50 years now, and basically it is a algorithm backed by a database; the database is the 'learning' (which shouldn't surprise anyone) and THAT is what 'modifies' the behaviour of code. David Rankin points out, quite correctly and pertinently:
It seems like there should be a preliminary question (or two), or at least an information box on the YAST partitioning page that could provide guidance here. Especially if it will help avoid problems.
Or a number of question. And a number of problems, And a better explanation to the user of limits and risks as David mentions There's nothing magic or mystic or difficult about "AI". I remember discussion with Terry Hewitt back in 1976 a problem with label-tags of on-screen objects as they were dragged across the screen. He said that solving it was algorithmically 'confounding'. Now we think nothing of it while programming GUIs and games. He also said that it wasn't worth bothering with as users would put up the overlapping of labels and objects and figure things out for themselves. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
04.09.2018 16:50, Richard Brown пишет: ...
Looking briefly at the thread it seems obvious to me that the user in question had a number of problems
1- an old installation with an old btrfs layout - modern btrfs installations have /var as a single subvolume.
How is it going to change anything if /var had actually been full?
2- a disk too small for their use - 40GB should be fine for many users, but that is just a default. After all anyone storing anything in /var, such as logs, is going to be 'robbing' space otherwise useful for snapshots
OP has barely 400MiB in the whole /var and 24GiB of lost snapshots for 11GiB in actual file system. Pick another straw man. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/04/2018 08:50 AM, Richard Brown wrote:
1. is a slight annoyance which anyone on any SUSE or openSUSE distribution before 15 needs to deal with
I even have to take my hat off to that diplomatic whitewash.... Meant constructively. That rivals the best political spin, and is akin to statements by M$, e.g., explaining the rash of blue-screens and 8 hour failed updates for the 1803 roll-out. ("some customers experienced slight difficulty with the upgrade...") The un-whitewashed version reads "Before 15, there were problems with btrfs". Why spin on a technical mailing list? This is one place where the discussion must be fact, statistic and code based. Why does it seem impossible to get a straight-answer regarding brtfs? <quote> Looking briefly at the thread it seems obvious to me that the user in question had a number of problems 1- an old installation with an old btrfs layout - modern btrfs installations have /var as a single subvolume. 2- a disk too small for their use - 40GB should be fine for many users, but that is just a default. After all anyone storing anything in /var, such as logs, is going to be 'robbing' space otherwise useful for snapshots </quote> WTF? Those are the YAST defaults. Is that the problem? If someone actually uses /var, then the defaults are insufficient for btrfs and that leads to / running out of space? Should YAST pick up on the "old btrfs layout" a change appropriately to avoid the slight annoyances? It seems like there should be a preliminary question (or two), or at least an information box on the YAST partitioning page that could provide guidance here. Especially if it will help avoid problems. /var holds the mail stores, fax stores, mysql tables, cups-pdf and a combination of other system and user files that can vary wildly in size. It would be useful to at least inform, if not have a separate question before the partitioning page in YAST to clarify "Do you have storage requirements for a large number of logs, mail users, a fax server or a large database that will require additional storage?" YAST adds a separate /var partition I just look from the standpoint of providing a btrfs set up that can be as fire-and-forget as reiser or ext4. If a few additional install questions or information boxes, and an update to the YAST partitioner will help -- let's do it -- so we eliminate these "slight annoyance" circumstances. No doubt progress is being made. We have gone from weekly "Root is full" posts to monthly or less -- to that's progress, but if the new user which opensuse has been geared to for the past decade is still have problems with the YAST default partitioning and filesystem selection -- then there is still more to do. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-09-04 17:30, David C. Rankin wrote:
On 09/04/2018 08:50 AM, Richard Brown wrote:
1. is a slight annoyance which anyone on any SUSE or openSUSE distribution before 15 needs to deal with
I even have to take my hat off to that diplomatic whitewash....
Meant constructively. That rivals the best political spin, and is akin to statements by M$, e.g., explaining the rash of blue-screens and 8 hour failed updates for the 1803 roll-out. ("some customers experienced slight difficulty with the upgrade...")
The un-whitewashed version reads "Before 15, there were problems with btrfs".
Why spin on a technical mailing list? This is one place where the discussion must be fact, statistic and code based. Why does it seem impossible to get a straight-answer regarding brtfs?
<quote> Looking briefly at the thread it seems obvious to me that the user in question had a number of problems
1- an old installation with an old btrfs layout - modern btrfs installations have /var as a single subvolume. 2- a disk too small for their use - 40GB should be fine for many users, but that is just a default. After all anyone storing anything in /var, such as logs, is going to be 'robbing' space otherwise useful for snapshots </quote>
WTF? Those are the YAST defaults.
Yes, indeed. Don't blame the user. And his problems was snapshots that the system had lost the accounting of, not logs or anything. So having /var differently would not help. So far, it looks as system error (design?), not user error. ...
I just look from the standpoint of providing a btrfs set up that can be as fire-and-forget as reiser or ext4. If a few additional install questions or information boxes, and an update to the YAST partitioner will help -- let's do it -- so we eliminate these "slight annoyance" circumstances.
Absolutely.
No doubt progress is being made. We have gone from weekly "Root is full" posts to monthly or less -- to that's progress, but if the new user which opensuse has been geared to for the past decade is still have problems with the YAST default partitioning and filesystem selection -- then there is still more to do.
Yep. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
The un-whitewashed version reads "Before 15, there were problems with btrfs".
I wouldn't phrase it like that. The issue is that you do not want to back up user/log data in system snapshots (as it would make them even larger). But you could not place whole /var in a subvolume because it still contained system- and version dependent stuff (like the rpm database). So point 1 was not an issue of btrfs, but only of system layout. This had been 'repaired' in Tumbleweed at some point, allowing to put /var into a single subvolume. An update of this was possible, but only offline (i.e., via a rescue system).
2- a disk too small for their use - 40GB should be fine for many users, but that is just a default. After all anyone storing anything in /var, such as logs, is going to be 'robbing' space otherwise useful for snapshots </quote>
WTF? Those are the YAST defaults.
ACK on that one, even more as in the old state (with the many /var subvolumes) changing the root size was non-trivial. But AFAIK this is fixed now, too.
Is that the problem? If someone actually uses /var, then the defaults are insufficient for btrfs and that leads to / running out of space? Should YAST pick up on the "old btrfs layout" a change appropriately to avoid the slight annoyances?
Not for btrfs. If someone creates tons of logfiles (running mail- and webservers) or uses it for development the default settings are on the low side for any system that doesn't just use the whole partition for everything...
It seems like there should be a preliminary question (or two), or at least an information box on the YAST partitioning page that could provide guidance here. Especially if it will help avoid problems.
You're talking about the past, is it? As I understood Leap 15 is already in a much improved state (single /var, quota enabled to monitor usage and auto-clean snapshots). Normal users *should* be on the safe side by now.
/var holds the mail stores, fax stores, mysql tables, cups-pdf and a combination of other system and user files that can vary wildly in size. It would be useful to at least inform, if not have a separate question before the partitioning page in YAST to clarify
"Do you have storage requirements for a large number of logs, mail users, a fax server or a large database that will require additional storage?"
YAST adds a separate /var partition
In general one might indeed consider offering this as an option, a radio button '/var on separate partition' and some explanations in the help.
No doubt progress is being made. We have gone from weekly "Root is full" posts to monthly or less -- to that's progress, but if the new user which opensuse has been geared to for the past decade is still have problems with the YAST default partitioning and filesystem selection -- then there is still more to do.
I think you'll have to wait a bit more. How many of such posts are from Leap 15 users? With the fixes you won't help any Leap 42.x or old TW user. Some care likely needs to be taken of upgraded systems, as that never(?) touches/changes the partitioning layout.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-09-04 9:50 a.m., Richard Brown wrote:
On Tue, 4 Sep 2018 at 15:40, Anton Aylward <opensuse@antonaylward.com> wrote:
Does the 'professional' side, Suse Corporate support, see this sort of thing? Do these problems beset the industrial/commercial of BtrFS?
If we were dealing with a pre-computer item that number of problems, problems with user management, then there would be serious questions about its design. Some things we deemed 'over-engineered'. In latter-day terms they weren't "user-friendly' as they needed a maintenance technician constantly at had. I'm sure some of us can recall a few classic IBM goofs of that nature.
By contrast we have a few very boring file systems. We deem them 'out of support' because no-one wants to work on them. Or perhaps the designers got them right the first time.
At one level it comes down to economics. With the over-egged system the vendor can charge the customers for ongoing support. The downside is that the vendor is better off it the support doesn't have to be carried out. And there's an even bigger downside if the customer has alternatives. IBM and Microsoft found that out.
Both their solutions were similar: build systems that are *reliable* and *easy* for the customer to manage and maintain himself.
Easy meaning that 'answers' to operational questions are obvious.
The problems that IBM faced, that M$ faces, is cost & inflexibility. Right now, those are the great advantages of Linux.
Well actually both are deceptive. There are hidden costs (like the need to have all this ongoing maintenance with the FS that Suse recommends (and note that RedHat doesn't).
And, given what CompSci research has achieved over the last quarter century, the still-monolithic CPU-bound process model that Linux (and the other UNIX derivatives) perpetuates and propagates, isn't that flexible.
But my main question is about whether or not the corporate side of Suse , its customers, have these problems with BtrFS as well.
Looking briefly at the thread it seems obvious to me that the user in question had a number of problems
1- an old installation with an old btrfs layout - modern btrfs installations have /var as a single subvolume. 2- a disk too small for their use - 40GB should be fine for many users, but that is just a default. After all anyone storing anything in /var, such as logs, is going to be 'robbing' space otherwise useful for snapshots
Yes, that would do it. It is why I ALWAYS have a separate /var so that if a stray, rogue or erroring system (or the kernel for that matter) fills /var/log or wherever systemd-journald is storing its DB I can still log in and do maintenance without havng to resort to booting from the maintenance CD. Or, and a separate FS for /tmp for the same purpose. I'm one of the people who see a "One File System to Rule Them All" approach, be it with BtrFS, LVM or Suns's ZFS as carrying philosophical risks. Well OK, so do other file systems; I've ranted against Ext4 and ReiserFS in the past. I'm an avid supporter of a few principles. One is Risk Management. Another is that I don't want to spend time doing sysadmin when I can do things that are actually productive in the sense that they are concerned with a OUTPUT in the sense of moving forward and accomplishing the 'new' rather than MAINTENANCE.
1. is a slight annoyance which anyone on any SUSE or openSUSE distribution before 15 needs to deal with, and does require attention to the paid to the individual contents of all the separate /var/* subvolumes. That said, the flattening of /var was mostly due to the needs of openSUSE Kubic not SUSE or regular openSUSE.
We Linux users despised the need for (past) MS-DOS and MS_windows to solve problems by "delete and reinstall". We've been proud of kernel modules, of being able to update to a new release with a 'zypper dup' after modifying /etc/zypp/repos.d/*. So far that is. Or has "15" broken that?
2. is a problem only for people who are not paying adequate attention to their own system, which would be atypical for SUSE customers.
The model of computing that we have from the 1040s onward of there being a technician around to 'maintain' the system, monitor the logs and functioning. But the overall trend of consumer technology and business process has been 'simplification'. We can see this most classically in automobiles. no longer do we maintain our own cars, no longer do we have dashboards that tell up about all manner of details, no longer to we listen to the sound of the engine to understand its performance, no longer do we lift the hood and 'check all the fluids'. The same applies to many other aspects of life. And look how much simpler the Linux boot sequence is. I no longer have to key in octal numbers at the front panel toggle switches .... no wait, that was not Cromenco, or was it the PDP-8? Corporations don't want all the fiddly bits of 'system administration' and they don't want to employ geeks and/or hackers - that's another risk isn't it? - on staff to do it for them. Everything is migrating to the "Cloud". The user end is getting simpler, mobile, heck why bother even maintaining a office space with the ret, heating, janitor service?
So, to answer your inflammatory question, corporate SUSE are very happy with their decision to use btrfs as their default root filesystem and their ongoing growth as a company can be at least partially attributed to the features available in SLE and CaaSP due to the extensive use of btrfs.
So, by that reasoning, it is not good sales technique and of course because Redhat decided NOT to lead with BtrFS, it is on the decline. Sorry, I dispute your causality. https://www.zdnet.com/article/red-hat-on-its-way-to-becoming-the-first-billi... https://www.redhat.com/en/about/press-releases/growing-number-organizations-... I think there is a lot more to it than your explanation and reasoning tries to cover. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 4 Sep 2018 at 14:43, Anton Aylward <opensuse@antonaylward.com> wrote:
1. is a slight annoyance which anyone on any SUSE or openSUSE distribution before 15 needs to deal with, and does require attention to the paid to the individual contents of all the separate /var/* subvolumes. That said, the flattening of /var was mostly due to the needs of openSUSE Kubic not SUSE or regular openSUSE.
We Linux users despised the need for (past) MS-DOS and MS_windows to solve problems by "delete and reinstall". We've been proud of kernel modules, of being able to update to a new release with a 'zypper dup' after modifying /etc/zypp/repos.d/*. So far that is. Or has "15" broken that?
We will continue to support the old filesystem layout indefinitely, but it comes with the added complexity of more subvolumes which many users find confusing when it comes to maintaining their system. To move from the old layout to the new layout, a fresh installation is recommended. Whether users do it or not, it a users choice.
Corporations don't want all the fiddly bits of 'system administration' and they don't want to employ geeks and/or hackers - that's another risk isn't it? - on staff to do it for them. Everything is migrating to the "Cloud". The user end is getting simpler, mobile, heck why bother even maintaining a office space with the ret, heating, janitor service?
Because you want to be in control of your system, set it up your way, and use it the way you wish to use it Which means you need to take responsibility for the choices you make, or do not make, with your system Which is why the openSUSE is configured the way it is.
So, to answer your inflammatory question, corporate SUSE are very happy with their decision to use btrfs as their default root filesystem and their ongoing growth as a company can be at least partially attributed to the features available in SLE and CaaSP due to the extensive use of btrfs.
So, by that reasoning, it is not good sales technique and of course because Redhat decided NOT to lead with BtrFS, it is on the decline.
Sorry, I dispute your causality. https://www.zdnet.com/article/red-hat-on-its-way-to-becoming-the-first-billi... https://www.redhat.com/en/about/press-releases/growing-number-organizations-...
I think there is a lot more to it than your explanation and reasoning tries to cover.
Ah .. allow me to humour you and your Red Hat shilling with some sources of my own https://www.suse.com/c/butter-bei-die-fische/ <- SUSE's corporate statement on Red Hats decision to abandon btrfs, a filesystem they were never working on anyway https://www.attachmate.com/company/news/press/2014/micro-focus-international... <- Micro Focus acquiring the whole Attachmate Group (including Attachmate, Borland, Micro Focus, NetIQ, Novell and SUSE. for $1.4 billion) 4 years later.. https://www.suse.com/c/news/suse-partners-with-growth-investor-eqt-to-contin... https://www.eqtpartners.com/news/Press-Releases/2018/eqt-to-acquire-leading-... SUSE (alone, not with the Attachmate Group) is soon to be acquired by EQT for $2.35billion. No matter how you cut it, that's a pretty astronomical business value increase in 4 short years..4 short year with btrfs being the default filesystem in all SUSE products I might add ;) More context: https://www.suse.com/c/news/suse-builds-momentum-with-innovative-open-source... Hope this helps.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-09-04 6:04 p.m., Richard Brown wrote:
Ah .. allow me to humour you and your Red Hat shilling with some sources of my own
You have so missed the point I was making. The issue isn't that SUSE is doing well; the issue is that RedHat is doing well, financially and in terms of customer base, despite abandoning BtrFS. I've worked with large mainframe/IBM (and other) instillations (with Petabyte and larger storage) and seen (and used) their commit/rollback file systems. And their file system virtualizations. I do understand the benefits. But I question the benefit outside of a 'corporate' setting. In this case I question the applicability. Having a FS of 10G or even 100G (or a 1T) is very different from those corporate setting. In addition, this thread has shown that something of this order requires more than an 'entry level' of experience. I'd go a bit further; to many Linux users the whole sophistication of what BtrFS does, offers, is beyond them. Automating network backup with Rsync is complex enough for them and their needs. And it is something that is understandable. And this response of yours still doesn't address the 'pressure to simplify' matter I raised. RedHat comes across as much more enthusiastic about Containers and 'Cloud Computing' than SUSE. I'm not shrilling for RedHat. I'm a openSUSE user who has chose not to use BtrFS. I've retired from being a sysadmin. What I AM doing is pointing out that RedHat is taking a view of the future of both small systems (encapsulation & virtualization, suitable for lightweight, 'chrome-book' style mobile working) and serving the 'Cloud Computing' side. By comparison, SUSE is less "aggressive" in this arena. https://www.redhat.com/en/about/press-releases/growing-number-organizations-... The BtrFS model is a good path to an implementation that IBM proved in the 1960s and onwards, a classical 'data centre' approach. For a single home user, SMB, entry level, I don't think it competes well with the more familiar file systems and backup/restore that people have long since got their minds around. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Sep 5, 2018 at 2:29 AM Anton Aylward <opensuse@antonaylward.com> wrote:
The BtrFS model is a good path to an implementation that IBM proved in the 1960s and onwards, a classical 'data centre' approach. For a single home user, SMB, entry level, I don't think it competes well with the more familiar file systems and backup/restore that people have long since got their minds around.
+1 We set up our systems with an OEM image that we build in KIWI. We have opted to stay with ext4 rather than btrfs. The primary reason is that our experience with btrfs shows that it requires care and feeding. I understand the benefits. But our user base are people who perform measurements. They are not people who manage computer systems. The fact that it is Linux and not Windows already required a bit of explanation. (As an aside, there are some interesting benefits in our use case: 1. the users are less likely to want to fiddle with things - which btrfs maintenance somewhat violates. 2. adding hardware is usually much more simple on Linux - the old hardware install woes were really addressed by Linux and the result is quite impressive, and 3. stability.) I just hope that an ext4-type layout as available via KIWI remains available. There is a serious user case for providing this. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-09-04 17:43, Anton Aylward wrote:
On 2018-09-04 9:50 a.m., Richard Brown wrote:
On Tue, 4 Sep 2018 at 15:40, Anton Aylward <> wrote:
...
1. is a slight annoyance which anyone on any SUSE or openSUSE distribution before 15 needs to deal with, and does require attention to the paid to the individual contents of all the separate /var/* subvolumes. That said, the flattening of /var was mostly due to the needs of openSUSE Kubic not SUSE or regular openSUSE.
We Linux users despised the need for (past) MS-DOS and MS_windows to solve problems by "delete and reinstall". We've been proud of kernel modules, of being able to update to a new release with a 'zypper dup' after modifying /etc/zypp/repos.d/*. So far that is. Or has "15" broken that?
Yes. Btrfs has broken it, rather. The btrfs layout in 15.0 has changed, and there is no automated way to upgrade the existing filesysystem.
2. is a problem only for people who are not paying adequate attention to their own system, which would be atypical for SUSE customers.
So, SUSE customer's systems do not have those problems, not because SLE is superior to openSUSE, but because they are managed by professionals. Thank you! ;-) People, don't use btrfs unless you are a professional and can take care of your system. That's the conclusion, sorry. QED. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-09-04 9:46 p.m., Carlos E. R. wrote:
People, don't use btrfs unless you are a professional and can take care of your system. That's the conclusion, sorry.
I (once upon a time) rate as a profession who managed a similar system for IBM sites. (In one case I was hired as an interim UNIX admin but all the UNIX machines interfaced in hardware with the IBM Mainframe so I ended up doing mainframe work most of the time since shell scripting for the UNIX machines was a doddle.) But here I am with a home network of a few machines, all running openSUSE, and I run a few FS, ext4 to boot from, ReiserFS and JFS for storage, and I won't touch BtrFS for theses 'small' (under 2T, under 1T, under 750G) machines. They run. A lot of what they run is scripts triggered by CRON and other 'automatons'. As a sysadmin I've done a 'fire and forget'. As log monitoring I believe in Marcus Ranum's "artificial ignorance". 99.998% of what gets logged I can ignore. The 0.002% I get emails about. Automation again. Scripts are wonderful. So is getting on with other stuff, like mailbombing this list :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
04.09.2018 15:03, Peter Suetterlin пишет:
I was more puzzled about the quota-related commands and cleanups. Those don't work for me, I only get "ERROR: can't list qgroups: quotas not enabled" Are they enabled by default on more recent installs?
Yes, to enable space-triggered snapshots cleanup. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
04.09.2018 15:03, Peter Suetterlin пишет:
I was more puzzled about the quota-related commands and cleanups. Those don't work for me, I only get "ERROR: can't list qgroups: quotas not enabled" Are they enabled by default on more recent installs?
Yes, to enable space-triggered snapshots cleanup.
Thanks! Sounds usefull indeed. I'll look into it :) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
2018-09-04 06:28 keltezéssel, Andrei Borzenkov írta:
03.09.2018 21:17, Albert Oszkó пишет: ...
0/278 188.95MiB 188.95MiB Starting from here ...
0/403 0.00B 0.00B 0/439 0.00B 0.00B 0/580 3.17GiB 16.00EiB 0/581 413.15MiB 16.00EiB 0/638 0.00B 0.00B ... to here there are stale entries. Those subvolumes no more exist. You should delete them
btrfs qgroup destroy 0/403 / ...
And then update quota information with
btrfs quota rescan -w /
then listing qgroup should be more close to reality
0/754 10.40GiB 9.86GiB 0/876 10.96GiB 3.59GiB 0/883 11.00GiB 2.24GiB 0/904 10.92GiB 2.96GiB 1/0 29.23GiB 23.45GiB And those "lost" snapshots consume 23.45GiB together.
255/269 16.00KiB 16.00KiB
I did what you said:
linux-olq5:~ # btrfs qgroup destroy 0/403 / linux-olq5:~ # btrfs quota rescan -w / quota rescan started You miunderstand (twice actually). Qgroup is just accounting information. When quota is enabled, qgroup is automatically created for each subvolume but it is not destroyed when subvolume is deleted. Normally snapper should remove qgroup when it removes snapshot, but that apparently did not happen in your case.
So suggestion was to simply clean up output to remove stale outdated information. And suggestion was to remove *all* of stale qgroups (those that do not have corresponding subvolume), not just one of them.
But removing qgroup is not going to change anything in how much space is consumed and it was not intended to.
linux-olq5:~ # btrfs qgroup show / qgroupid rfer excl -------- ---- ---- ... 0/754 10.40GiB 9.86GiB 0/876 10.96GiB 3.59GiB 0/883 11.00GiB 2.24GiB 0/904 10.92GiB 2.96GiB 1/0 29.23GiB 23.45GiB You still have those old snapshots that apparently lost their metadata and so are not "visible" to snapper.
ID 754 gen 265167 top level 258 path @/.snapshots/64/snapshot ID 876 gen 336471 top level 258 path @/.snapshots/142/snapshot ID 883 gen 336471 top level 258 path @/.snapshots/148/snapshot ID 904 gen 341810 top level 258 path @/.snapshots/164/snapshot
If you are absolutely sure you do not need them, you should remove them. This will gain you 23.45GiB. Also remove corresponding subdirectories under /.snapshots so as to not confuse snapper
btrfs su del /.snapshots/64/snapshot rm -r /.snapshots/64 ... etc
You are right, I misunderstood your text. But by now I managed to delete those - as you call - stale snapshots, so I have plenty of space on root. But as just for many in the list below, it came into my mind, whether is this the proper choice ( I mean btrfs) for a normal or average user? The commands you wrote and the effectiveness of them delighted me, but as a nearly average user, should I know them? After all, many thanks for your help. I save it for the future. Albert
On 2018-09-04 1:18 p.m., Albert Oszkó wrote:
But as just for many in the list below, it came into my mind, whether is this the proper choice ( I mean btrfs) for a normal or average user? The commands you wrote and the effectiveness of them delighted me, but as a nearly average user, should I know them?
Yes, that's a very apropos question. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-09-03 12:40 p.m., Albert Oszkó wrote:
This Asus laptop (with TW and KDE) was not used for ten days. Yesterday evening I switched it on and saw I have >800 updates. I tried tio install them with zypper dup. I failed, because root got full.
Possibly snapshots but also possibly the RPMs.
I managed to boot into 4.17.14 kernel (got some complaints, but none showstopper) and manually remove all downloaded rpm packages from /var/cache/zypp/packages with mc.
There are two issues here. One is that you have /var on the same FS as /. This is something that BtrFS installations lead to and something I consider pernicious. I'm a great believer in HARD partitioning, that is putting /var on a separate FS. that way if it fills you don't have a full ROOTFS. Of course you could set the cache to some empty FS: ## ## Path where the caches are kept. ## ## Valid values: A directory ## Default value: /var/cache/zypp ## # cachedir = /var/cache/zypp The second is that you have Zypper set up to download ALL of the 800+ RPMs before installing any. This is a setting in /etc/zypp/zypp/zypp.conf I avoid you situation since I have this set to DownLoadAsNeeded. The 'default' is not smart; it ends up as DownloadInAdvance ## ## Commit download policy to use as default. ## ## DownloadOnly, Just download all packages to the local cache. ## Do not install. Implies a dry-run. ## ## DownloadInAdvance, First download all packages to the local cache. ## Then start to install. ## ## DownloadInHeaps, Similar to DownloadInAdvance, but try to split ## the transaction into heaps, where at the end of ## each heap a consistent system state is reached. ## ## DownloadAsNeeded Alternating download and install. Packages are ## cached just to avid CD/DVD hopping. This is the ## traditional behaviour. ## ## <UNSET> If a value is not set, empty or unknown, we pick ## some sane default. ## ## commit.downloadMode = commit.downloadMode = DownloadAsNeeded -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
2018-09-03 19:38 keltezéssel, Anton Aylward írta:
On 2018-09-03 12:40 p.m., Albert Oszkó wrote:
This Asus laptop (with TW and KDE) was not used for ten days. Yesterday evening I switched it on and saw I have >800 updates. I tried tio install them with zypper dup. I failed, because root got full. Possibly snapshots but also possibly the RPMs.
I managed to boot into 4.17.14 kernel (got some complaints, but none showstopper) and manually remove all downloaded rpm packages from /var/cache/zypp/packages with mc. There are two issues here.
One is that you have /var on the same FS as /. This is something that BtrFS installations lead to and something I consider pernicious. I'm a great believer in HARD partitioning, that is putting /var on a separate FS. that way if it fills you don't have a full ROOTFS.
Of course you could set the cache to some empty FS:
## ## Path where the caches are kept. ## ## Valid values: A directory ## Default value: /var/cache/zypp ## # cachedir = /var/cache/zypp
The second is that you have Zypper set up to download ALL of the 800+ RPMs before installing any. This is a setting in /etc/zypp/zypp/zypp.conf I avoid you situation since I have this set to DownLoadAsNeeded. The 'default' is not smart; it ends up as DownloadInAdvance
## ## Commit download policy to use as default. ## ## DownloadOnly, Just download all packages to the local cache. ## Do not install. Implies a dry-run. ## ## DownloadInAdvance, First download all packages to the local cache. ## Then start to install. ## ## DownloadInHeaps, Similar to DownloadInAdvance, but try to split ## the transaction into heaps, where at the end of ## each heap a consistent system state is reached. ## ## DownloadAsNeeded Alternating download and install. Packages are ## cached just to avid CD/DVD hopping. This is the ## traditional behaviour. ## ## <UNSET> If a value is not set, empty or unknown, we pick ## some sane default. ## ## commit.downloadMode = commit.downloadMode = DownloadAsNeeded
Dear Anton, This last section answered what would be my next question: how could I modify the download all rpms first and then install them method. I did not ever modify this setting (not even knowing of this) so this was the default here. I give it a try. Albert
On Tuesday, September 4, 2018 12:38:27 AM WIB Anton Aylward wrote:
On 2018-09-03 12:40 p.m., Albert Oszkó wrote:
This Asus laptop (with TW and KDE) was not used for ten days. Yesterday
The second is that you have Zypper set up to download ALL of the 800+ RPMs before installing any. This is a setting in /etc/zypp/zypp/zypp.conf I avoid you situation since I have this set to DownLoadAsNeeded. The 'default' is not smart; it ends up as DownloadInAdvance
A very interesting discussion. Found the proposed setting interesting, the setting of " DownLoadAsNeeded" in the config " /etc/zypp/zypp/zypp.conf" but to my amazement I do not have that a /etc/zypp/zypp/ directory. What are my possibilities to get a complete zypp setup? In the same context, If I do a akonadictl vacuum it is works at high speed. Also missing something? -- opensuse:tumbleweed:20180903 Qt: 5.11.1 KDE Frameworks: 5.49.0 - KDE Plasma: 5.13.4 - kwin 5.13.4 kmail2 5.9.0 - - Kernel: 4.18.5-1-default -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Constant Brouerius van Nidek wrote:
On Tuesday, September 4, 2018 12:38:27 AM WIB Anton Aylward wrote:
On 2018-09-03 12:40 p.m., Albert Oszkó wrote:
This Asus laptop (with TW and KDE) was not used for ten days. Yesterday
The second is that you have Zypper set up to download ALL of the 800+ RPMs before installing any. This is a setting in /etc/zypp/zypp/zypp.conf I avoid you situation since I have this set to DownLoadAsNeeded. The 'default' is not smart; it ends up as DownloadInAdvance
A very interesting discussion. Found the proposed setting interesting, the setting of " DownLoadAsNeeded" in the config " /etc/zypp/zypp/zypp.conf" but to my amazement I do not have that a /etc/zypp/zypp/ directory. What are my possibilities to get a complete zypp setup?
Confused. You say you found the setting in /etc/zypp/zypp/zypp.conf, and then claim you don't have the /etc/zypp/zypp/ directory? I'd think the other posting just has a 'zypp' too many. I neither have the /etc/zypp/zypp/ directory, the config is in /etc/zypp/zypp.conf -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-09-06 12:37 a.m., Constant Brouerius van Nidek wrote:
On Tuesday, September 4, 2018 12:38:27 AM WIB Anton Aylward wrote:
On 2018-09-03 12:40 p.m., Albert Oszkó wrote:
This Asus laptop (with TW and KDE) was not used for ten days. Yesterday
The second is that you have Zypper set up to download ALL of the 800+ RPMs before installing any. This is a setting in /etc/zypp/zypp/zypp.conf I avoid you situation since I have this set to DownLoadAsNeeded. The 'default' is not smart; it ends up as DownloadInAdvance
A very interesting discussion. Found the proposed setting interesting, the setting of " DownLoadAsNeeded" in the config " /etc/zypp/zypp/zypp.conf" but to my amazement I do not have that a /etc/zypp/zypp/ directory. What are my possibilities to get a complete zypp setup?
Apologies. My Typo ... stuttering .. That should be: /etc/zypp/zypp.conf # ls -l /etc/zypp/zypp.conf -rw-r--r-- 1 root root 19217 Aug 1 2017 /etc/zypp/zypp.conf And hmm, I'm surprised you couldn't find it it with a find /etc -name 'zypp.conf' -print Some things become reflex to more experienced CLI users. They end up doing locate 'zypp.conf' But then again, you can have a lot of fun with 'find', feeding its output into other like like 'awk' .... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday, September 6, 2018 9:51:28 PM WIB Anton Aylward wrote:
On 2018-09-06 12:37 a.m., Constant Brouerius van Nidek wrote:
On Tuesday, September 4, 2018 12:38:27 AM WIB Anton Aylward wrote:
On 2018-09-03 12:40 p.m., Albert Oszkó wrote:
This Asus laptop (with TW and KDE) was not used for ten days. Yesterday
The second is that you have Zypper set up to download ALL of the 800+ RPMs before installing any. This is a setting in /etc/zypp/zypp/zypp.conf I avoid you situation since I have this set to DownLoadAsNeeded. The 'default' is not smart; it ends up as DownloadInAdvance
A very interesting discussion. Found the proposed setting interesting, the setting of " DownLoadAsNeeded" in the config " /etc/zypp/zypp/zypp.conf" but to my amazement I do not have that a /etc/zypp/zypp/ directory. What are my possibilities to get a complete zypp setup?
Apologies. My Typo ... stuttering ..
That should be: /etc/zypp/zypp.conf # ls -l /etc/zypp/zypp.conf -rw-r--r-- 1 root root 19217 Aug 1 2017 /etc/zypp/zypp.conf
And hmm, I'm surprised you couldn't find it it with a
find /etc -name 'zypp.conf' -print
Some things become reflex to more experienced CLI users. They end up doing
locate 'zypp.conf'
But then again, you can have a lot of fun with 'find', feeding its output into other like like 'awk' ....
> Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. >> >>> Q: Why is top posting frowned upon?
Thanks for the clarification. -- opensuse:tumbleweed:20180903 Qt: 5.11.1 KDE Frameworks: 5.49.0 - KDE Plasma: 5.13.4 - kwin 5.13.4 kmail2 5.9.0 - akonadiserver 5.9.0 - Kernel: 4.18.5-1-default -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (10)
-
Albert Oszkó -
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
Constant Brouerius van Nidek -
Dave Howorth -
David C. Rankin -
Peter Suetterlin -
Richard Brown -
Roger Oberholtzer