Dotaz: Btrfs - Uncorrectable corruption errors

[xxl]

Zdravím vespolek. Mám nový SSD disk, na kterém mám jednu partiton s EFI a druhou s BTRFS. BTRFS mi hlásí chyby tohoto typu:

Aug 13 20:08:34 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 363, gen 0
Aug 13 20:08:34 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 364, gen 0
Aug 13 20:08:34 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 162185342976 on dev /dev/sda2
Aug 13 20:08:34 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 162185371648 on dev /dev/sda2

Provedel jsem smart kontrolou disku, různé testování souborového systému i pokusy o jeho opravu. Z testování a z čtení diskusí na internetu jsem usoudil, že se asi nejedná o hardwarovou chybu disku, ani počítače a že problém se patrně týká neobsazeného prostoru na disku, kde se původně nacházel nějaký, teď již vymazaný, soubor. To by odpovídalo tomu, jakým způsobem nejspíš došlo k vytvoření té chyby, resp. tomu, co jsem prováděl, když se chyba objevila. (Měl jsem puštěné virtuální Windows z qcow2 image, který nebyl nocow a ty Windowsy jsem odstřelil, protože byly neskutečně pomalé po upgradu z Debianu Buster na Bullseye a následně jsem ten image file vymazal, protože při jeho čtení docházelo k chybám.) Takže se snažím opravit souborový systém a nejde mi to.

# btrfs scrub status /
UUID:             e6497e96-c4a7-4431-868c-3f6878f753c9
Scrub started:    Fri Aug 13 20:05:03 2021
Status:           finished
Duration:         0:19:10
Total to scrub:   603.59GiB
Rate:             537.45MiB/s
Error summary:    csum=44
  Corrected:      0
  Uncorrectable:  44
  Unverified:     0

Přečetl jsem všechny soubory na disku:

# find /mnt -type f -exec cp -v {} /dev/null \; 2> corrupted-files.txt # + kontrola logu

bez jakékoliv chyby. Provedl jsem repair:

# btrfs check --repair --check-data-csum /dev/sda2

a nic. Chyby jsou tam pořád. Použít volbu --init-csum-tree jsem se neodvážil, ale mám podezření, že je to moje poslední šance.

Rád bych věděl, jestli se dá souborový systém opravit bez formátování. Nebo se mám bát o to, že je špatný samotný disk? A pokud by tedy byl, jak bych měl doložit, že mu něco je?



Další informace:

# uname -a
Linux notebook 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 GNU/Linux

# btrfs --version
btrfs-progs v5.10.1 

# btrfs fi show
Label: none  uuid: e6497e96-c4a7-4431-868c-3f6878f753c9
	Total devices 1 FS bytes used 600.34GiB
	devid    1 size 931.26GiB used 615.07GiB path /dev/sda2

# btrfs fi df /
Data, single: total=605.01GiB, used=597.09GiB
System, DUP: total=32.00MiB, used=96.00KiB
Metadata, DUP: total=5.00GiB, used=3.25GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

# btrfs dev stats /
[/dev/sda2].write_io_errs    0
[/dev/sda2].read_io_errs     0
[/dev/sda2].flush_io_errs    0
[/dev/sda2].corruption_errs  375
[/dev/sda2].generation_errs  0

# LC_ALL=C journalctl --no-hostname -b -k | grep BTRFS
Aug 13 19:10:57 kernel: BTRFS: device fsid e6497e96-c4a7-4431-868c-3f6878f753c9 devid 1 transid 34401 /dev/sda2 scanned by btrfs (318)
Aug 13 19:10:57 kernel: BTRFS info (device sda2): disk space caching is enabled
Aug 13 19:10:57 kernel: BTRFS info (device sda2): has skinny extents
Aug 13 19:10:57 kernel: BTRFS info (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 331, gen 0
Aug 13 19:10:57 kernel: BTRFS info (device sda2): enabling ssd optimizations
Aug 13 19:10:57 kernel: BTRFS info (device sda2): use lzo compression, level 0
Aug 13 19:10:57 kernel: BTRFS info (device sda2): disk space caching is enabled
Aug 13 20:05:03 kernel: BTRFS info (device sda2): scrub: started on devid 1
Aug 13 20:06:24 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 332, gen 0
Aug 13 20:06:24 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 71976439808 on dev /dev/sda2
Aug 13 20:06:32 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 333, gen 0
Aug 13 20:06:32 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 76319760384 on dev /dev/sda2
Aug 13 20:06:49 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 334, gen 0
Aug 13 20:06:49 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 85945815040 on dev /dev/sda2
Aug 13 20:07:02 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 335, gen 0
Aug 13 20:07:02 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 93501964288 on dev /dev/sda2
Aug 13 20:07:10 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 336, gen 0
Aug 13 20:07:10 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 97784770560 on dev /dev/sda2
Aug 13 20:07:10 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 337, gen 0
Aug 13 20:07:10 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 97784774656 on dev /dev/sda2
Aug 13 20:07:10 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 338, gen 0
Aug 13 20:07:10 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 97784782848 on dev /dev/sda2
Aug 13 20:07:21 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 339, gen 0
Aug 13 20:07:21 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 340, gen 0
Aug 13 20:07:21 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 341, gen 0
Aug 13 20:07:21 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 104154996736 on dev /dev/sda2
Aug 13 20:07:21 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 104154894336 on dev /dev/sda2
Aug 13 20:07:21 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 104155054080 on dev /dev/sda2
Aug 13 20:07:21 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 342, gen 0
Aug 13 20:07:21 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 344, gen 0
Aug 13 20:07:21 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 104155004928 on dev /dev/sda2
Aug 13 20:07:21 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 104154898432 on dev /dev/sda2
Aug 13 20:07:21 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 104155058176 on dev /dev/sda2
Aug 13 20:07:21 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 345, gen 0
Aug 13 20:07:21 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 346, gen 0
Aug 13 20:07:21 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 347, gen 0
Aug 13 20:07:21 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 104155070464 on dev /dev/sda2
Aug 13 20:07:21 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 104155009024 on dev /dev/sda2
Aug 13 20:07:21 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 348, gen 0
Aug 13 20:07:21 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 104154902528 on dev /dev/sda2
Aug 13 20:07:21 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 104155095040 on dev /dev/sda2
Aug 13 20:07:21 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 349, gen 0
Aug 13 20:08:34 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 358, gen 0
Aug 13 20:08:34 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 162185232384 on dev /dev/sda2
Aug 13 20:08:34 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 162185089024 on dev /dev/sda2
Aug 13 20:08:34 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 359, gen 0
Aug 13 20:08:34 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 360, gen 0
Aug 13 20:08:34 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 162185236480 on dev /dev/sda2
Aug 13 20:08:34 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 162185363456 on dev /dev/sda2
Aug 13 20:08:34 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 361, gen 0
Aug 13 20:08:34 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 362, gen 0
Aug 13 20:08:34 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 162185240576 on dev /dev/sda2
Aug 13 20:08:34 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 162185367552 on dev /dev/sda2
Aug 13 20:08:34 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 363, gen 0
Aug 13 20:08:34 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 364, gen 0
Aug 13 20:08:34 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 162185342976 on dev /dev/sda2
Aug 13 20:08:34 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 162185371648 on dev /dev/sda2
Aug 13 20:08:34 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 365, gen 0
Aug 13 20:08:34 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 162185375744 on dev /dev/sda2
Aug 13 20:08:34 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 366, gen 0
Aug 13 20:08:34 kernel: BTRFS error (device sda2): unable to fixup (regular) error at logical 162185392128 on dev /dev/sda2
Aug 13 20:08:34 kernel: BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 367, gen 0
Aug 13 20:24:13 kernel: BTRFS info (device sda2): scrub: finished on devid 1 with status: 0

# smartctl -x /dev/sda
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-8-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     Samsung SSD 870 EVO 1TB
Serial Number:    xxxxxxxxxxxxxxx
LU WWN Device Id: 5 002538 fc13e22b6
Firmware Version: SVT01B6Q
User Capacity:    1 000 204 886 016 bytes [1,00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
TRIM Command:     Available, deterministic, zeroed
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Fri Aug 13 23:46:31 2021 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM feature is:   Unavailable
Rd look-ahead is: Enabled
Write cache is:   Enabled
DSN feature is:   Unavailable
ATA Security is:  Disabled, frozen [SEC2]
Wt Cache Reorder: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		(    0) seconds.
Offline data collection
capabilities: 			 (0x53) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					No Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 (  85) minutes.
SCT capabilities: 	       (0x003d)	SCT Status supported.
					SCT Error Recovery Control supported.
					SCT Feature Control supported.
					SCT Data Table supported.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
  5 Reallocated_Sector_Ct   PO--CK   100   100   010    -    0
  9 Power_On_Hours          -O--CK   099   099   000    -    194
 12 Power_Cycle_Count       -O--CK   099   099   000    -    60
177 Wear_Leveling_Count     PO--C-   099   099   000    -    1
179 Used_Rsvd_Blk_Cnt_Tot   PO--C-   100   100   010    -    0
181 Program_Fail_Cnt_Total  -O--CK   100   100   010    -    0
182 Erase_Fail_Count_Total  -O--CK   100   100   010    -    0
183 Runtime_Bad_Block       PO--C-   100   100   010    -    0
187 Reported_Uncorrect      -O--CK   100   100   000    -    0
190 Airflow_Temperature_Cel -O--CK   072   051   000    -    28
195 Hardware_ECC_Recovered  -O-RC-   200   200   000    -    0
199 UDMA_CRC_Error_Count    -OSRCK   100   100   000    -    0
235 Unknown_Attribute       -O--C-   099   099   000    -    29
241 Total_LBAs_Written      -O--CK   099   099   000    -    2398698749
                            ||||||_ K auto-keep
                            |||||__ C event count
                            ||||___ R error rate
                            |||____ S speed/performance
                            ||_____ O updated online
                            |______ P prefailure warning

General Purpose Log Directory Version 1
SMART           Log Directory Version 1 [multi-sector log support]
Address    Access  R/W   Size  Description
0x00       GPL,SL  R/O      1  Log Directory
0x01           SL  R/O      1  Summary SMART error log
0x02           SL  R/O      1  Comprehensive SMART error log
0x03       GPL     R/O      1  Ext. Comprehensive SMART error log
0x04       GPL,SL  R/O      8  Device Statistics log
0x06           SL  R/O      1  SMART self-test log
0x07       GPL     R/O      1  Extended self-test log
0x09           SL  R/W      1  Selective self-test log
0x10       GPL     R/O      1  NCQ Command Error log
0x11       GPL     R/O      1  SATA Phy Event Counters log
0x13       GPL     R/O      1  SATA NCQ Send and Receive log
0x30       GPL,SL  R/O      9  IDENTIFY DEVICE data log
0x80-0x9f  GPL,SL  R/W     16  Host vendor specific log
0xa1           SL  VS      16  Device vendor specific log
0xa5           SL  VS      16  Device vendor specific log
0xce           SL  VS      16  Device vendor specific log
0xe0       GPL,SL  R/W      1  SCT Command/Status
0xe1       GPL,SL  R/W      1  SCT Data Transfer

SMART Extended Comprehensive Error Log Version: 1 (1 sectors)
No Errors Logged

SMART Extended Self-test Log Version: 1 (1 sectors)
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%       193         -
# 2  Extended offline    Completed without error       00%       163         -
# 3  Short offline       Completed without error       00%       157         -
# 4  Extended offline    Completed without error       00%       110         -
# 5  Short offline       Completed without error       00%        91         -
# 6  Extended offline    Completed without error       00%        24         -
# 7  Short offline       Completed without error       00%        22         -
# 8  Extended offline    Completed without error       00%         1         -
# 9  Short offline       Completed without error       00%         0         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
  256        0    65535  Read_scanning was never started
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

SCT Status Version:                  3
SCT Version (vendor specific):       256 (0x0100)
Device State:                        Active (0)
Current Temperature:                    28 Celsius
Power Cycle Min/Max Temperature:     25/48 Celsius
Lifetime    Min/Max Temperature:     -1/66 Celsius
Specified Max Operating Temperature:    70 Celsius
Under/Over Temperature Limit Count:   0/0
SMART Status:                        0xc24f (PASSED)

SCT Temperature History Version:     2
Temperature Sampling Period:         10 minutes
Temperature Logging Interval:        10 minutes
Min/Max recommended Temperature:      0/70 Celsius
Min/Max Temperature Limit:            0/70 Celsius
Temperature History Size (Index):    128 (85)

Index    Estimated Time   Temperature Celsius
  86    2021-08-13 02:30    44  *************************
  87    2021-08-13 02:40    46  ***************************
  88    2021-08-13 02:50    31  ************
  89    2021-08-13 03:00    29  **********
  90    2021-08-13 03:10    29  **********
  91    2021-08-13 03:20    28  *********
  92    2021-08-13 03:30    27  ********
  93    2021-08-13 03:40    26  *******
 ...    ..( 10 skipped).    ..  *******
 104    2021-08-13 05:30    26  *******
 105    2021-08-13 05:40    25  ******
 106    2021-08-13 05:50    25  ******
 107    2021-08-13 06:00    25  ******
 108    2021-08-13 06:10    26  *******
 109    2021-08-13 06:20    26  *******
 110    2021-08-13 06:30    25  ******
 ...    ..(  2 skipped).    ..  ******
 113    2021-08-13 07:00    25  ******
 114    2021-08-13 07:10    26  *******
 ...    ..(  2 skipped).    ..  *******
 117    2021-08-13 07:40    26  *******
 118    2021-08-13 07:50    27  ********
 119    2021-08-13 08:00    26  *******
 120    2021-08-13 08:10    26  *******
 121    2021-08-13 08:20    27  ********
 122    2021-08-13 08:30    28  *********
 123    2021-08-13 08:40     ?  -
 124    2021-08-13 08:50    25  ******
 125    2021-08-13 09:00    25  ******
 126    2021-08-13 09:10    25  ******
 127    2021-08-13 09:20    26  *******
   0    2021-08-13 09:30    26  *******
   1    2021-08-13 09:40    26  *******
   2    2021-08-13 09:50    25  ******
   3    2021-08-13 10:00    26  *******
   4    2021-08-13 10:10     ?  -
   5    2021-08-13 10:20    25  ******
   6    2021-08-13 10:30    26  *******
 ...    ..( 21 skipped).    ..  *******
  28    2021-08-13 14:10    26  *******
  29    2021-08-13 14:20    27  ********
  30    2021-08-13 14:30    26  *******
 ...    ..(  2 skipped).    ..  *******
  33    2021-08-13 15:00    26  *******
  34    2021-08-13 15:10    27  ********
 ...    ..(  2 skipped).    ..  ********
  37    2021-08-13 15:40    27  ********
  38    2021-08-13 15:50    28  *********
  39    2021-08-13 16:00    30  ***********
  40    2021-08-13 16:10    35  ****************
  41    2021-08-13 16:20    31  ************
  42    2021-08-13 16:30    31  ************
  43    2021-08-13 16:40    31  ************
  44    2021-08-13 16:50    32  *************
  45    2021-08-13 17:00    36  *****************
  46    2021-08-13 17:10    31  ************
  47    2021-08-13 17:20    31  ************
  48    2021-08-13 17:30    30  ***********
  49    2021-08-13 17:40    29  **********
  50    2021-08-13 17:50    29  **********
  51    2021-08-13 18:00    32  *************
  52    2021-08-13 18:10    30  ***********
  53    2021-08-13 18:20    35  ****************
  54    2021-08-13 18:30    33  **************
  55    2021-08-13 18:40    30  ***********
  56    2021-08-13 18:50    30  ***********
  57    2021-08-13 19:00    34  ***************
  58    2021-08-13 19:10    32  *************
  59    2021-08-13 19:20    30  ***********
  60    2021-08-13 19:30    31  ************
  61    2021-08-13 19:40    30  ***********
  62    2021-08-13 19:50    31  ************
  63    2021-08-13 20:00    31  ************
  64    2021-08-13 20:10    47  ****************************
  65    2021-08-13 20:20    48  *****************************
  66    2021-08-13 20:30    35  ****************
  67    2021-08-13 20:40    30  ***********
  68    2021-08-13 20:50    31  ************
  69    2021-08-13 21:00    29  **********
 ...    ..(  2 skipped).    ..  **********
  72    2021-08-13 21:30    29  **********
  73    2021-08-13 21:40    40  *********************
  74    2021-08-13 21:50    43  ************************
  75    2021-08-13 22:00    44  *************************
  76    2021-08-13 22:10    42  ***********************
  77    2021-08-13 22:20    41  **********************
  78    2021-08-13 22:30    41  **********************
  79    2021-08-13 22:40    40  *********************
  80    2021-08-13 22:50    40  *********************
  81    2021-08-13 23:00    36  *****************
  82    2021-08-13 23:10    30  ***********
  83    2021-08-13 23:20    29  **********
  84    2021-08-13 23:30    28  *********
  85    2021-08-13 23:40    28  *********

SCT Error Recovery Control:
           Read: Disabled
          Write: Disabled

Device Statistics (GP Log 0x04)
Page  Offset Size        Value Flags Description
0x01  =====  =               =  ===  == General Statistics (rev 1) ==
0x01  0x008  4              60  ---  Lifetime Power-On Resets
0x01  0x010  4             194  ---  Power-on Hours
0x01  0x018  6      2398698749  ---  Logical Sectors Written
0x01  0x020  6         8751712  ---  Number of Write Commands
0x01  0x028  6     15916088482  ---  Logical Sectors Read
0x01  0x030  6        21036464  ---  Number of Read Commands
0x01  0x038  6         1095000  ---  Date and Time TimeStamp
0x04  =====  =               =  ===  == General Errors Statistics (rev 1) ==
0x04  0x008  4               0  ---  Number of Reported Uncorrectable Errors
0x04  0x010  4               0  ---  Resets Between Cmd Acceptance and Completion
0x05  =====  =               =  ===  == Temperature Statistics (rev 1) ==
0x05  0x008  1              28  ---  Current Temperature
0x05  0x020  1              66  ---  Highest Temperature
0x05  0x028  1              -1  ---  Lowest Temperature
0x05  0x058  1              70  ---  Specified Maximum Operating Temperature
0x06  =====  =               =  ===  == Transport Statistics (rev 1) ==
0x06  0x008  4             661  ---  Number of Hardware Resets
0x06  0x010  4               0  ---  Number of ASR Events
0x06  0x018  4               0  ---  Number of Interface CRC Errors
0x07  =====  =               =  ===  == Solid State Device Statistics (rev 1) ==
0x07  0x008  1               0  N--  Percentage Used Endurance Indicator
                                |||_ C monitored condition met
                                ||__ D supports DSN
                                |___ N normalized value

Pending Defects log (GP Log 0x0c) not supported

SATA Phy Event Counters (GP Log 0x11)
ID      Size     Value  Description
0x0001  2            0  Command failed due to ICRC error
0x0002  2            0  R_ERR response for data FIS
0x0003  2            0  R_ERR response for device-to-host data FIS
0x0004  2            0  R_ERR response for host-to-device data FIS
0x0005  2            0  R_ERR response for non-data FIS
0x0006  2            0  R_ERR response for device-to-host non-data FIS
0x0007  2            0  R_ERR response for host-to-device non-data FIS
0x0008  2            0  Device-to-host non-data FIS retries
0x0009  2        14363  Transition from drive PhyRdy to drive PhyNRdy
0x000a  2           40  Device-to-host register FISes sent due to a COMRESET
0x000b  2            0  CRC errors within host-to-device FIS
0x000d  2            0  Non-CRC errors within host-to-device FIS
0x000f  2            0  R_ERR response for host-to-device data FIS, CRC
0x0010  2            0  R_ERR response for host-to-device data FIS, non-CRC
0x0012  2            0  R_ERR response for host-to-device non-data FIS, CRC
0x0013  2            0  R_ERR response for host-to-device non-data FIS, non-CRC

Odpovědi

[Andrej]

Chyby jsou tam pořád.

Jako že zůstávají v metadatech zaznamenané i po odstranění těch poškozených souborů?

No to jo, to zůstávají, právě proto, aby se po chybě a po případném následném odstranění postižených souborů (nebo aspoň přepsání postižených bloků) (možná automatickém, bez vědomí uživatele) na celý „incident“ nezapomnělo.

Co třeba:

btrfs device stats -z /dev/sda2

Pokud se po tomhle^^^ chyby objevují stále (== znova), bude fakt něco špatně s hardwarem.

Rád bych věděl, jestli se dá souborový systém opravit bez formátování.

Otázka je, jestli je rozbitý nebo jestli jsou tam jen pozůstatky uložených „stats“.

Nebo se mám bát o to, že je špatný samotný disk?

Pokud se po vymazání statistik a intenzivním psaní / čtení chyby objeví zas, pak ano, může být špatný disk / kabel / řadič / RAM.

Ad RAM: Má ten stroj ECC? Hlásí ECC něco? Bez ECC se nedá nic rozumně ukládat; při dnešních velikostech a „spolehlivostech“ RAM je to ruská ruleta. DDR5 bude mít ECC povinně a popivvě.

Pokud to nemá ECC, pár hodin memtestu na zkoušku neuškodí.

A pokud by tedy byl, jak bych měl doložit, že mu něco je?

Huh? Doložit? Komu? Proč?

Spotřební béčkový domácí hardware (typu Samsung Evo nebo Samsung Jindřiško) dnes stojí pět korun padesát. Úsilí spojené s „dokládáním“ něčeho v 999‰ případů bude stát víc než ten hardware.

Kdykoliv se mi něco podobného stalo (posledně třeba s odpadními SMR disky Mořskábrána), většinou jsem to sice výrobci nahlásil, pokud mě to nestálo víc než tak hodinu času, ale tím to haslo; disky jsou v elektrošrotu, všech 10 kousků, minimálně dalších 5 let Mořskábrána moje peníze neuvidí a hotovo.

Reklamací bych nezískal absolutně nic — maximálně výměnu z výroby a z principu rozbitého křápu za tentýž křáp.

5.10.0-8-amd64 #1 SMP Debian 5.10.46-4

Off-topic / mimochodem: Vřele doporučuji vždy používat současný kernel, nikoliv fosilii. Neexistuje důvod, aby distro mělo kernel víc než týden pozadu za kernel.org. Pokud to tak je, jde o špatné distro, kterému je dobré se vyhnout.

(Kdyby šlo (hypoteticky) o bug, nikdo z vývojářů by asi nebyl ochoten zabývat se předpotopním kernelem z minulého roku.)

[trekker.dk]

Off-topic / mimochodem: Vřele doporučuji vždy používat současný kernel, nikoliv fosilii. Neexistuje důvod, aby distro mělo kernel víc než týden pozadu za kernel.org. Pokud to tak je, jde o špatné distro, kterému je dobré se vyhnout.

(Kdyby šlo (hypoteticky) o bug, nikdo z vývojářů by asi nebyl ochoten zabývat se předpotopním kernelem z minulého roku.)

Jenom upozornění pro původního tazatele: autor citovaného příspěvku žije ve své vlastní realitě, která úplně nesouhlasí s realitou, ve které žijeme my ostatní a ve které je tenhle kernel plně podporovaný. Není tedy třeba se plašit, pokud by se skutečně jednalo o chybu v software, opravu v tomhle kernelu dostanete taky.

[Andrej]

Není tedy třeba se plašit, pokud by se skutečně jednalo o chybu v software, opravu v tomhle kernelu dostanete taky.

A tady máme opět klasické trekker.dk-style odtržení od reality a totální nepochopení, která b(l)ije.

O případném backportu nějaké opravy do fosilních kernelů (které – opakuji – nemají na desktopu co dělat) se rozhodne teprve poté, co se (zatím hypotetický) bug podaří reprodukovat a opravit na současném kernelu, dřív ne.

Proto je vhodné připomínat důležitost aktuálních kernelů, aktuálního software a dobrých distribucí obecně, zejména v situaci, kdy se uživatel potýká s dosud ne zcela vysvětleným problémem.

[ewew]

A ty čo používaš ? Archeologický systém ?

[Andrej]

Distra, která používám, mají aktuální kernel.

[LarryL]

Má to i druhou stranu mince. Nejnovější kernel = nové funkce = větší pravděpodobnost nových bugů.

[Andrej]

Ano, ale vždycky je lepší nový bug než starý bug. U toho nového je šance, že ho ještě někdy někdo opraví.

[LarryL]

V LTS kernelu opraví i ten starý, ale je mnohem menší šance, že tam bude nový bug. Ale jinak souhlasím, že na desktopu je dobré mít nejnovější kernel, tam se nehraje na nějaku super stabilitu. Navíc musí to někdo otestovat před tím než se daný kernel použije na serverech.

[trekker.dk]

Jediné klasické je vaše odtržení od reality. Ještě chybí, abyste lhal, jak to máte také ve zvyku.

[Andrej]

Bla, bla, bla. Potrefená husa marně vříská.

Kde přesně jsem lhal? Chtělo by to odkaz nebo držet zobák.

[trekker.dk]

Potrefená husa marně vříská.

Ano, to vřískáte, s tím nic nenadělám.

Kde přesně jsem lhal? Chtělo by to odkaz nebo držet zobák.

Jedna z předchozích diskuzí. Odkaz jste dostal tam.

[Kit]

Klidně si rozkopejte bábovičky, ale někde jinde.

[trekker.dk]

Reagujete do špatné pozice v diskuzi

[Andrej]

Takže odkaz není. Přesně podle očekávání.

Nezbývá než smajlík déčko.

[trekker.dk]

Odkaz je. V té předchozí diskuzi. Pokud neumíte hledat ve vlastních příspěvcích, to je váš problém

[Petr Fiedler]

Ahoj Andreji,
věděl bys prosím tě jak otestovat, že ECC RAM funguje se vším všudy? Odsud dolů.

@xxl: Omlouvám se za OT.

[Andrej]

Většinou pokud dmidecode říká, že tam ECC je, a error reporting všeho druhu je u procesoru zapnutý (v UEFI setupu i v kernelu), je to v pohodě.

Taky existuje nějaký error injector pro testování reakcí kernelu na chyby, ale nikdy jsem nic takového nepoužil.

[Petr Fiedler]

THX

[xxl]

Díky za odpověď.

Pokud to nemá ECC, pár hodin memtestu na zkoušku neuškodí.

ECC to nemá, memtest jsem provedl. Bez problémů.

btrfs device stats -z /dev/sda2

Tohle podle mě pouze vynuluje counter, ale nijak to neovlivní strukturu filesystému a ty chyby, které to hlásí při scrubu. Nicméně jsem to provedl a následně jsem znovu provedl scrub. Pořád stejné, akorát se ty chyby v device stats a v logu začaly počítat od nuly.

Takže smarttest disku nic nehlásí, všechny soubory jdou přečíst bez chyb. Scrub hlásí crc chyby, jejichž počet je pořád stejný. V logu se objevují chyby, ale právě jenom tehdy, když provádím scrub. Umístění těch chyb se nedají přiřadit ke konkrétním souborům ani pomocí btrfs inspect-internal logical-resolve. V logu nejsou žádná jména souborů, pouze jednou, úplně na začátku, se tam objevilo jméno toho qcow2 image virtuálních Windows, který jsem potom smáznul v domnění, že prostě soubor je poškozený, já ho smáznu, obnovím a jedeme dál.

Teď ještě zkusím přečíst celý disk pomocí dd, ale moc nevěřím, že na něco přijdu.

[.-]

Nepoužívej silně problematický fs btrfs a nebudeš mít problémy

[Aleš Kapica]

Sám si silně problematický…

[Andrej]

…nebudeš mít problémy…

Různí anonymní idioti se občas mylně domnívají, že "nevědět o problémech" == "nemít problémy".

Spoiler alert: Není to totéž.

Zatímco dobrý FS (Btrfs, ZFS) přesně v tomto případě (opět) dokázal odhalit problematický hardware, problematický FS (tedy FS bez checksumů dat i metadat) by tentýž problém ještě notnou dobu neodhalil a uživatel by celou věc zaregistroval třeba až po pár měsících, až budou jeho data (včetně záloh!) rozbitá a náhodně kontaminovaná.

Tak celkově by to chtělo méně anti-Btrfs idiotů — je rok 2021, nikoliv 2009 nebo kdy byl Btrfs posledně „nestabilní“.

[Andrej]

Tohle podle mě pouze vynuluje counter, ale nijak to neovlivní strukturu filesystému a ty chyby, které to hlásí při scrubu.

Jo, přesně to bylo cílem — zjistit, jestli se chyby po vynulování statistik objeví znovu. Bohužel tedy ano.

U rotujícího ne-SMR disku by mělo smysl se ptát, jestli se pokaždé vážou ke stejným LBA, ale u SSD žádná pevná vazba mezi LBA a hardwarem není… Kdyby tam byl (hypoteticky) hardwarový problém, může se postupně „objevovat“ v různých LBA.

Já osobně bych asi v takové situaci zkusil udělat bitovou kopii na jiné SSD (což s sebou může nést jisté náklady, ale záloha se při podezření na potíže s hardwarem tak či onak hodí) a zkusil bych scrub tam.

No a pokud je to nějaký bug typu poškození (nepříliš kritických) metadat (nepříliš kritických == když tedy lze všechny soubory přečíst a jejich čtení negeneruje další chyby…), která scrub neumí opravit ani odstranit, pak by to jistě byl (zajímavý) případ pro kernelovou buggillu a mailing listy.

[bigBRAMBOR]

Jo, přesně to bylo cílem — zjistit, jestli se chyby po vynulování statistik objeví znovu. Bohužel tedy ano.

to je jak u automechanika, tam taky prvni krok k vyreseni zavady je vynulovani chyb a pockani jestli se objevi jeste. Cekani na zazrak ze sami zmizí.

[Aleš Kapica]

Jo, přesně to bylo cílem — zjistit, jestli se chyby po vynulování statistik objeví znovu. Bohužel tedy ano.

to je jak u automechanika, tam taky prvni krok k vyreseni zavady je vynulovani chyb a pockani jestli se objevi jeste. Cekani na zazrak ze sami zmizí.

Co tě na tom překvapuje? Je to naprosto normální postup, pokud potřebuješ zjistit zda-li šlo o problém, který byl v mezičase odstraněn, nebo ne.

Abych byl konkrétní. Řada lidí si neuvědomuje jak choulostivé jsou konektory. Zcela běžně se stává že ze zástrček povylézají nejenom ethernetové kabely, ale také SATA kabely a dokonce i PCIe zařízení. Pokud ti povyleze SATA kabel, a začnou blbnout kontrakty, tak se ti začnou objevovat chyby, které nejsou pro Btrfs fatální, ale pochopitelně je zaznamená. Pokud konektor dotlačíš, tak se objevovat přestanou. V případě, že ti povyleze PCIe řadič ti zmizí celé disky. Podobný problém může nastat také v případě, že je problém s kontaktem u napájení – to je důvod, proč se vyhýbám modulárním kabelům.

Stalo se mi, když jsem ještě používal MD raid, že jsem se jen lehce opřel o kabel, a pak nezbylo než čekat 9 hodin, než se pole opět zesynchronizovalo. U Btrfs v raid módu se tohle neděje, ale pochopitelně se to zaznamená do logu a jeho vynulování je jediná cesta, jak zjistit, jestli jde o záznam starého incidentu, nebo jde o aktuální problém.

[bigBRAMBOR]

sorry nedoslo mi, ze nekdo nepouziva datum pri procitani logu, omlouvam se

[Aleš Kapica]

Jsou různé chyby a i takové, které ve standardním logu nenajdeš, protože se objevují jen občas a za určitých okolností.

[Aleš Kapica]

Viz třeba problém, který byl zmíněn v diskuzi k Maxově blogpostu SSD a zničení běžným používáním? Možná to jde.... Dodnes nevím skutečnou příčinu. Tři SSD disky. Dva ok, při zapojení třech brutálně zpomalený FS. Starší SSD disky 2x Samsung, 1x Kingston, všechny 250GB. Bylo úplně jedno jak byly nakombinované a do jakých portů zapíchnuté. V logu žádná chyba. Nakonec jsem se naštval, koupil místo nich 2x nový Samsung EVO 860 512GB a byl klid. Nenapadlo mě podrobně prozkoumat jejich smart log, až Maxův blogpost naznačil možnou příčinu – opotřebení.

[Andrej]

Na tom tě překvapuje co přesně?

Když mám Btrfs pole sestávající s flashdisků v hubu a půlku ho náhodně odpojím, věř tomu, že při dalším připojení pak opravdu (ale opravdu) budu chtít ty chyby vynulovat, protože neříkají nic, co by odpovídalo současnému stavu systému a jsou tam jenom proto, aby uživatel věděl (což ví), že v minulosti kdysi došlo k posrání připojení k půlce pole.

Žádný zázrak v tom netkví.

[xxl]

Já osobně bych asi v takové situaci zkusil udělat bitovou kopii na jiné SSD ... a zkusil bych scrub tam.

To jsem neprováděl, protože nemám volný SSD disk a už bych to asi nervově nevydržel. Zálohu mám.

Rozžehnal jsem se s daty a provedl jsem

# btrfs check --repair --init-csum-tree /dev/sda2

Mraky nějakých hlášení typu:

ref mismatch on [1462395944960 16384] extent item 1, found 0
backref 1462395944960 root 7 not referenced back 0x5589f4da0d80
incorrect global backref count on 1462395944960 found 1 wanted 0
backpointer mismatch on [1462395944960 16384]
owner ref check failed [1462395944960 16384]
repair deleting extent record: key [1462395944960,169,0]
Repaired extent references for 1462395944960

Missing extent item in extent tree for disk_bytenr 153016442880, num_bytes 249856
Missing extent item in extent tree for disk_bytenr 153395150848, num_bytes 315392
Missing extent item in extent tree for disk_bytenr 111695663104, num_bytes 303104
Missing extent item in extent tree for disk_bytenr 153028231168, num_bytes 372736

root 2311 inode 340 errors 800, odd csum item
root 2312 inode 260 errors 800, odd csum item
root 2314 inode 257 errors 800, odd csum item
ERROR: errors found in fs roots
found 643762806784 bytes used, error(s) found
total csum bytes: 624818280
total tree bytes: 3404529664
total fs tree bytes: 2564161536
total extent tree bytes: 203603968
btree space waste bytes: 481775282
file data blocks allocated: 1954303500288
 referenced 784495185920

WARNING: reserved space leaked, flag=0x4 bytes_reserved=1146880
extent buffer leak: start 1095305838592 len 16384
WARNING: dirty eb leak (aborted trans): start 1095305838592 len 16384
extent buffer leak: start 1097453273088 len 16384
WARNING: dirty eb leak (aborted trans): start 1097453273088 len 16384
extent buffer leak: start 1095306100736 len 16384

Nemám to všechno, zapomněl jsem to zaznamenat, ale mám asi 10000 řádek z konzole. V logu během akce žádná chyba. Když jsem to viděl, říkal jsem si, že data jsou nejspíš fuč. Namontoval jsem disk (bez problůmů) a provedl jsem scrub. Úplně bez problémů. Device stats samé nuly.

Odmontoval jsem disk a provedl jsem

# btrfs check /dev/sda2

s asi takovým výsledkem

[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
Missing extent item in extent tree for disk_bytenr 1694152658944, num_bytes 61440
Missing extent item in extent tree for disk_bytenr 1692857667584, num_bytes 4096
Missing extent item in extent tree for disk_bytenr 1692857692160, num_bytes 20480

root 262 inode 370 errors d00, file extent discount, nbytes wrong, odd csum item
Found file extent holes:
	start: 4128436224, len: 53877739520

root 348 inode 988365 errors 800, odd csum item
root 348 inode 988366 errors 800, odd csum item
root 348 inode 988367 errors 800, odd csum item

root 399 inode 289145 errors 2001, no inode item, link count wrong
	unresolved ref dir 38831 index 7 namelen 17 name user-1000.journal filetype 1 errors 4, no inode ref
root 399 inode 300166 errors 2001, no inode item, link count wrong
	unresolved ref dir 2869 index 21 namelen 18 name basic.target.wants filetype 2 errors 4, no inode ref

ERROR: errors found in fs roots
Opening filesystem to check...
Checking filesystem on /dev/sda2
UUID: e6497e96-c4a7-4431-868c-3f6878f753c9
found 644285390848 bytes used, error(s) found
total csum bytes: 625252300
total tree bytes: 3445374976
total fs tree bytes: 2602778624
total extent tree bytes: 205012992
btree space waste bytes: 490006298
file data blocks allocated: 2407376396288
 referenced 843735949312

Prostě mraky chyb, tohle je jen ukázka. --repair vyhodil to samé, akorát se to snažil nějak opravovat a po vícero průchodech se ustálil asi na 13000 řádcích úplně stejného výsupu. Tj. vypisoval chyby, snažil se je opravit, stále dokola to stejné.

Smarttest úplně OK. Btrfs scrub úplně OK. Btrfs check --repair, mraky chyb. Nicméně systém (notebook) nejspíš plně funkční, nepřišel jsem na nic, co by nefungovalo. Zkoušel jsem pouštět virtuální stroje, linux z cow image s vnitřním filesystémem btrfs, windows z nocow image. Ty image předtím přečkaly ty hokusy pokusy. Všechno to fungovalo. A v systémovém logu se od opravy csum-tree neobjevila žádná chyba ani varování ohledně btrfs.

Nicméně, přestalo mě to bavit, další pokusy jsem zavrhl a znovu jsem to naformátoval.

Podle mě to celé vzniklo tím vynuceným resetem virtuálních Windows spuštěných z cow image disku (což se jaksi nedoporučuje).

[LarryL]

Podle mě to celé vzniklo tím vynuceným resetem virtuálních Windows spuštěných z cow image disku (což se jaksi nedoporučuje).

Jako vím, že se na Btrfs wiki doporučuje pro adresáře ve kterých jsou image VM vypnout copy-on-write for single files/directories do: $ chattr +C /dir/file, ale to je kvůli výkonu, aby Btrfs nemuselo pořád provádět copy-on-write s obrovským image disku VM, ale rozhodně by to nemělo způsobit rozbití Btrfs. Ten soubor qcow2 je pořád jenom obyčejný soubor a Btrfs to musí (měl by) zvládnout.

[xxl]

Nevím. Ale jak jsem tak hledal informace po internetu, tak jsem narazil i na diskuse, kde se psalo, že při určitém nastavení cache pro virtuální Qemu/KVM stroj k tomu dochází.

Ty Windowsy (puštěné v Debianu Bullseye v Qemu/KVM pomocí Virt-Manageru) něco dělaly a prakticky nereagovaly. Já je odstřelil. Pak jsem ten jejich image chtěl kopírovat, ale už v něm byly chyby.

Následně jsem si udělal nový image, tentokrát s nocow a pustil jsem ho. Windowsy zase téměř nereagovaly. Ale vydržel jsem a povedlo se mi je korektně ukončit. Pak jsem rebootoval notebook do Debianu Buster a z toho samého image na tom samém btrfs filesystému jsem bez problémů ty Windowsy stejným způsobem spustil a ony dost svižně reagovaly. Prostě v Busteru to běhalo svižně, v Bullseye prakticky vůbec, opakovaně. A proto si myslím, že je tam někde něco shnilého softwarově a já to tím vynuceným vypnutím virtuálního stroje podpořil.

[LarryL]

Ale jak jsem tak hledal informace po internetu, tak jsem narazil i na diskuse, kde se psalo, že při určitém nastavení cache pro virtuální Qemu/KVM stroj k tomu dochází.

Tak když nastavíš cache=writeback nebo cache=unsafe, tak by měl být běh VM rychlejší, ale může při pádu VM nebo hostitele dojít ke ztrátě dat uvnitř VM, protože si VM myslí, že data byly uloženy na disk, ale ve skutečnosti nebyly uloženy. To může mít za následek, že bude VM s Windowsem nabíhat pomalu, protože bude něco opravovat, ale pořád jsou to nějaké jedničky a nuly uvnitř souboru *.qcow2 a Btrfs je srdečně úplně jedno, že Windows VM má nějaký problém. Pro Btrfs je to pořád jen jeden z mnoha souborů bez ohledu jestli je uvnitř Windows nebo nějaké porno.

[xxl]

Tady je 8 let stará diskuse, která popisuje něco podobného.

[LarryL]

Takže je to v podstatě tento btrfs bug, který byl, podle posledního komentáře, opraven v polovině roku 2012. Btrfs špatně detekovalo chybu. Pokud tvoje Btrfs není staré 9 let, tak to tvůj problém být nemůže.

[xxl]

Moje Brtfs je přiměřeně aktuální, viz předchozí příspěvky.

Teď jsem ty zatracené Windowsy znovu nakonfiguroval v Debianu Bullseye, tj. nepoužil jsem konfiguraci přetaženou z Busteru, jako předtím, když došlo k té chybě. Těm Windowsům jsem podstrčil image, na který jsem si stěžoval, že v Bullseye nefungoval, zatímco v Busteru ano a který jsem si okopíroval bokem z toho btrfs, které vypisovalo ty tísíce řádků problémů při btrfs check --repair, a který jsem teď nahrál nazpátek na nově naformátované btrfs. Tentokrát jsem ho nechal copy-on-write. Ty Windowsy běhají úplně bez problémů a ještě svižněji, než v předtím Busteru.

Porovnal jsem starou a novou konfiguraci těch virtuálních strojů a hlavní rozdíl je, že původně jsem měl iothreads 1 a emulator /usr/bin/kvm, a teď mám iothreads nenastaveno a emulator /usr/bin/qemu-system-x86_64, což předpokládám výrazně ovlivnilo výkon a následně to přispělo i k poškození btrfs.

Takže bych si přeci jenom dovolil usuzovat, že tam nějaký ten problém bude. A to pravděpodobně ve spolupráci qemu a btrfs, pokud je ten virtuální stroj blbě nakonfigurovaný, což teď vidím, že byl můj případ.

[LarryL]

To co popisuješ je, že v Bullseye již není balíček qemu-kvm, ale je místo něj nyní qemu-system-x86. Jestli iothreads nějak ovlivnil výkon nedokážu říct. Možná před tím k pomalosti Windows přispěla i velká fragmentace, pokud Btrfs na tu VM používalo copy-on-write.

Každopádně z toho co jsi napsal mně pořád nijak nevyplývá žádný důkaz, že problém způsobilo Qemu. To že špatná konfigurace Qemu způsobila rozbití filesystému považuji za nepravděpodobné. Špatná konfigurace je v tvém případě jen změna u iothreads.

[ajtacka]

Je to sice uz par let, jenom odporuceni na btrfs filesystem je tu stale. Vtedy nebyl v debiane ani nastroje na check a repair, jenze suse to odporucalo pre svojich zakaznikov, protoze tento neni zatim user friendly a nejenom to. Redhat to uz nedela. A pro do production jit na fedore nemam slov

[Petr Fiedler]

na Btrfs wiki doporučuje pro adresáře ve kterých jsou image VM vypnout copy-on-write for single files/directories do: $ chattr +C /dir/file

A jak bych to měl udělat, když nemám qcow2's ve /var/lib/libvirt/images, ale v /data/data_giga/qemu_kvm? Mám tam Mint, Mint2 a Win10. Ve fstabu pak mám:

/data/data_giga/qemu_kvm    /var/lib/libvirt/images    none    bind,x-gvfs-hide    0    0

Asi před měsícem jsem přešel na Btrfs a ještě s tím moc neumím.

[LarryL]

Tady je popis s Btrfs Wiki. Atribut NOCOW (za použití nástroje chattr s +C) lze nastavit pro soubory i adresáře. U prázdného souboru lze přidat atribut NOCOW, nebo lze vytvořit nový soubor v adresáři s atributem NOCOW (nový soubor pak zdědí tento atribut).

Asi bych na tvém místě použil jejich script:

Použití:

# - vytvoř nový btrfs subvolume s nodatacow mount option

# - přesuň všechny qcow2 soubory do nového subvolume

# - spusť příkaz: find <SPEC> | xargs uncow.py

Pozn. Místo <SPEC> specifikuj jména qcow2 souborů.

Před použitím scriptu si qcow2 soubory pro jistotu zálohuj. Script je po překopírování vymaže. Tím, že budeš mít qcow2 v samostatném subvolume je budeš moci vyjmout ze snapshotů.

[Petr Fiedler]

Díky moc!

# fallocate -l 10M cow_file
# touch nocow_file
# chattr +C nocow_file 
# ls -l 
total 10240
-rw-r--r-- 1 root root 10485760 Aug 16 23:49 cow_file
-rw-r--r-- 1 root root        0 Aug 16 23:49 nocow_file
# lsattr   
---------------------- ./cow_file
---------------C------ ./nocow_file
# cp -f cow_file nocow_file 
# ls -l
total 20480
-rw-r--r-- 1 root root 10485760 Aug 16 23:49 cow_file
-rw-r--r-- 1 root root 10485760 Aug 16 23:50 nocow_file
# lsattr   
---------------------- ./cow_file
---------------C------ ./nocow_file

[Petr Fiedler]

Dík

[j]

Btrfs rozhodne neprovadi CoW se soubory, ale s bloky. Takze pokud se na tom image nic moc nemeni, tak se neprovadi ani zadny extra kopirovani dat. Kdyz se neco meni, funguje to uplne stejne jako s libovolnym jinym souborem = kopiruje se zmenenej blok. Respektive, zapisuje se do prazdnyho mista na disku, coz muze byt ve skutecnosti i rychlejsi, nez jeho prepis. Jediny co muze byt casem problem je fragmentace.

---

Dete s tim guuglem dopice!

[LarryL]

OK COW se provádí s bloky. Ale je to VM Windows, který hodně swapuje, takže těch zkopírovaných bloků odhaduju, že budou řádově GB až desítky GB za den, podle druhu práce a podle toho kolik RAM přidělí dané VM.

[Petr Fiedler]

A kdybys pro VM Windows přidělil např. 4GB RAM a ve Windows vypnul stránkování, tak by to bylo lepší, ne? Otázkou je, jaký by mělo dopad, kdybys třeba před spuštěním VM udělal snapshot (myslím ve virt-manageru) a pak v naběhlých Windows např. spustil aktualizaci OS.

[Petr Fiedler]

O tomhle nemluvě.

[LarryL]

4GB RAM pro Win10 se mi zdá málo. Když jsem si ladil Win10 ve VM, aby fungoval optimálně, tak jsem zkusil spoustu možností, ale stránkování jsem nikdy nevypl, ani si nevzpomínám, že by to někdy někdo doporučoval pro optimální chod VM. Teď si ani neuvědomuju co udělá Win10 když mu ty 4GB RAM dojdou. Podle mne si to stránkování vynutí i když ho v nastavení zakážeš. Virtuálce Win10 přiřazuji od 10GB RAM více. Jen třeba u testovací VM na chvíli dám ty 4GB.

[Petr Fiedler]

Když jsem si ladil Win10 ve VM, aby fungoval optimálně, tak jsem zkusil spoustu možností, ale stránkování jsem nikdy nevypl, ani si nevzpomínám, že by to někdy někdo doporučoval pro optimální chod VM.

Řeč ale nebyla o optimálním chodu VM. O vypnutí stránkování jsem napsal kvůli Btrfs:

@j:
Btrfs rozhodne neprovadi CoW se soubory, ale s bloky. Takze pokud se na tom image nic moc nemeni, tak se neprovadi ani zadny extra kopirovani dat.

@ty:
OK COW se provádí s bloky. Ale je to VM Windows, který hodně swapuje, takže těch zkopírovaných bloků odhaduju, že budou řádově GB až desítky GB za den, podle druhu práce a podle toho kolik RAM přidělí dané VM.

@já:
A kdybys pro VM Windows přidělil např. 4 GB RAM a ve Windows vypnul stránkování, tak by to bylo lepší, ne?

Prostě by se zapisovalo do RAM a ne do qcow2, ne?

Co se týká přiřazené RAM, tak dost záleží, jak kdo VM Windows používá. Samotné Windows mi zabírají ~1,7 GB RAM. Při aktualizaci kolem 2,5 GB. Já v nich pouštím buďto Chrome s 1 tabem, nebo jeden wordový soubor a jeden program. Takže já osobně přes 2,5 GB zabrané RAM nejdu. Chápu ale, že pro někoho je i 10 GB málo.

Co se týká výkonu, tak RAM je vždy rychlejší, než jakékoliv blokové zařízení. Takže vypnout stránkování by teoreticky mělo být lepší, ovšem prakticky to ani nemusí být moc znát. Když máš kupříkladu NVMe r / w = 5 GBps / 4,4 GBps, tak tam to asi opravdu nepoznáš. IMHO!

[LarryL]

Ano každé zamezení zbytečného čtení/zápisu na disk je dobré. Je to dobré pro Btrfs, životnost disku, i výkon. Pokud máš ověřené, že 4GB RAM ti pro Windows stačí a nebude si vynucovat zápis do stránkovacího souboru (i přes zákaz v nastavení), tak je to dobrá volba. I tak ti Windows bude dělat neustále zápisy do žurnálu, do registrů, do logů atd., ale to už vypnout nejde.

To, že jsou 4GB RAM málo jsem psal proto, že když spustím VM na klasickém HDD, tak mám subjektivní pocit, že víc hrabe na disk aniž bych dělal něco náročného.

[4321]

na ty "fosilii" te napr netrapi tohle: https://bugzilla.kernel.org/show_bug.cgi?id=212185

[lertimir]

Myslím si, že chyby máš jinde než souboru, který jsi smazal. Kdysi mě btrfs upozorňoval na odcházející HDD a hledal jsem chyby takto:

dmesg | grep "checksum error at" | tail -44 | cut -d\  -f24- | sed 's/.$//'

Číslo v tail odpovídá počtu chyb v btrfs scrub, pro tebe tedy 44. Jsem si na 99% jist, že scrub počítá jen v obsazeném prostoru. Mě se přesně odpovídajícím způsobem sníčila časová náročnost pro scrub, když jsem nepotřebná data vymazal a z 80% se obsazenost FS snížila na 20%.

[lertimir]

Jo a ten příkaz právě poslat po provedeném scrubu.

[xxl]

Psal jsem to výše.

Chyba v souboru se vypsala právě jednou. Jenže já ten soubor následně smazal. Pak už se nikdy neobjevila chyba, kterou by btrfs přiřadil nějakému souboru.

# journalctl --no-hostname | grep "checksum error at"
Aug 11 22:17:22 kernel: BTRFS warning (device sda2): checksum error at logical 656320602112 on dev /dev/sda2, physical 594110685184, root 262, inode 366, offset 5065203712, length 4096, links 1 (path: win10.qcow2)

[Aleš Kapica]

Vždyť to je jasné. Pokud hlásí checksum error, tak to znamená že checksum příslušného bloku uložený v metadatech Btrfs nesedí se skutečností, jelikož se po sejmutí virtuálu už nestihnl vypočítat a uložit.

Podle mě se to dalo spravit přes qemu-img s volbou check na příslušný qcow2 soubor. Jak se zdá, řešil jsi problém na nižší úrovni, než bylo třeba.

Jinak u velkých souborů virtuálních disků (které nemají atribut nocow) může nastat u Btrfs problém s jejich odstraněním, pokud není dost volného místa, nebo je-li zaplněna kvóta (pokud je tedy používáš). V takovém případě představuje elegantní řešení truncate, kterým srazíš velikost na 0, a pak už s odstraněním nebude problém.

[trekker.dk]

tak to znamená že checksum příslušného bloku uložený v metadatech Btrfs nesedí se skutečností, jelikož se po sejmutí virtuálu už nestihnl vypočítat a uložit.

Pro ostatní - kernel se ohledně toho, jestli checksum nějakého bloku dat vypočítá nebo ne, téměř na 100% neřídí tím, že proces, který ten blok zapsal, už neběží.

[Aleš Kapica]

Jistě, jenže při virtualizaci do toho nekecá jen kernel.

[j]

Kapica, neblabol tu kraviny. Filesystemu je zcela u prdele, co kdo s kterym souborem dela, natoz jestli nejakej virtual bezi nebo ne. Filesystem rozhodne naprosto nezajima nejakej virtual, naprosto netusi, ze tam nejakej je, a totez plati i opacne, ten virtual ma klidne nejakej svuj fs, ale pracuje s nim uvnitr toho svyho souboru. Rozhodne nemuze nijak ovlivnit to, co se zapise nebo nezapise. Takze ten virtual si sam sobe klidne ten svuj fs znicit (logicky) muze, ale z hlediska souboru a jeho citelnosti to nema zadnej vliv.

Chyba crc muze vzniknuot bud chybou HW nebo chybou SW (kernelu) nebo nejakym zasahem typu vytrzeni z elektricky zasuvky(pokud neni zaply CoW). Rozhodne nemuze vzniknout jakoukoli operaci nad souborem.

Jinak zjevne naprosto netusis jak btrfs funguje, protoze blok se oznaci prislusnosti k souboru teprve potom, kdy je korektne zapsan. Presne tohle zajistuje prave i tady zminovany CoW. Takze kdyby zapis z libovolnyho duvodu nedopad korektne, zustane soubor v podobe pred zapisem.

Laskave se v dokumentaci douc, ze specielne u btrfs jsou prakticky vsechny operace (vcetne deduplikaci, scrubu ...) napsany tak, ze i kdyz je v prubehu vypnes, a to i natvrdo, tak se nic nestane. Samozrejme za to zaplatis jistou dan v podobe vykonu, kterej bude horsi, nez u FS ktery to neresej.

---

Dete s tim guuglem dopice!

[Aleš Kapica]

Předpokládám, že ti níže uvedený příspěvek autora dotazu neuniknul. Vistualizací se zaobírám přes 20 let a Btrfs všude možně i nemožně používám také pěknou řádku let, tak nepoučuj a nedělej nohy.

[trekker.dk]

Koukám, že se Kapicabot po prázdninách strávených učením zase rozjel. A jako obvykle úplně mimo, příspěvky ve formě náhodné odkazů a nesmyslných tvrzení, která nesouvisí s tím, co je diskutováno ve vlákně.

[Aleš Kapica]

Jako obvykle se můžeš jít vycpat Bourku. Mi je srdečně jedno co si o mně tvá chorá hlava myslí. Pokud tobě smysl nedává to co napsal o kousek níže LarryL, tak mně jo a ty symptomy tomu odpovídají.

Důležité je, jaký závěr si z toho udělá tazatel, ne ty.

[trekker.dk]

Nepřekvapil jste, soudruhu komunisto kapicabote, urážky ano, zdůvodnění, proč by měla virtualizace mít na situaci jakýkoliv vliv - tedy zdůvodnění nezdůvodnitelného - chybí.

[Want]

Urážky?! Kup si nové zrcadlo, protože to stávající máš poněkud křivé.

A pokud nechápeš souvislisti mezi virtuálem, pamětí, swapem a FS, pak by ses měl sám doučit. Řešil jsem podobný problém u kamarádky cca před třemi lety, kdy mi celá zoufalá volala, že jí přestal fungovat widlácký virtuál, na kterém měla data cca za tři měsíce provozu své čerstvě rozjeté veterinární ordinace. Měla štěstí, že jsem při své poslední návštěvě udělal pro jistotu snapshot, takže přišla jen o měsíc dat. Nestalo by se, kdyby mi zavolala dříve, než se to pokusila řešit sama.

[trekker.dk]

Soudruhu anonymně přispívající komunisto kapicabote, můžete být klidný, souvislosti samozřejmě chápu, ale podle všeho vy ne, takže tady lidi krmíte nesmyslama.

[Aleš Kapica]

Klidně se dál Bourku prezentuj jako kretén. Je to tvoje volba.

[trekker.dk]

Jedna věc k naučení umělé inteligenci, soudruhu komunisto kapicabote, "dál" implikuje pokračování činnosti, která trvá, což se na mě v tomto případě nevztahuje. Případ, na který se to vztahuje, je například diskuze na úrovni "chybné tvrzení - urážka - nesouvisející historka - žádné podložení vlastních tvrzení", jak to tady předvádíte vy a nejspíš i dál předvádět budete

[LarryL]

Nechápu. V příspěvku na který odkazuješ tazatel popisuje, že vytvořil swap na komprimovaném subvolumu. To s VM nemá nic společného.

Jestli swapfile na komprimovaném subvolumu mohl způsobit problémy, které tazatl popisuje je zase jiná otázka.

[xxl]

Jestli swapfile na komprimovaném subvolumu mohl způsobit problémy, které tazatl popisuje je zase jiná otázka.

Byl bych skoro radši, kdyby ano...

[LarryL]

U VM jsem si skoro jistý, že to nebylo příčinou problémů. U swapfile to neumím říct, zas tak daleko moje znalosti do Btrfs nesahají, ale vím, že když se zakládá swapfile, tak filesystém s ním nepracuje jako se souborem, ale kernel namapuje bloky ve swapfile a pracuje přímo s bloky. Swapfile zůstává pořád na stejném místě na disku, dokud ho nezrušíš a nevytvoříš nový swapfile. Tak že by tvůj problém mohl být v tom, že v místě kde máš namapovaný swapfile se nacházejí vadné sektory a firmware disku je nedokáže realocovat? To by i odpovídalo tomu že ti scrub nehlásil žádný název souboru, který se nachází na vadných sektorech, právě proto, že swapfile není soubor. Ale tuhle moji úvahu ber s rezervou, ale rozhodně by to dávalo větší smysl než obviňovat sestřelenou virtuálku.

[xxl]

Když se na klasickém plotnovém disku vyhradí partition pro swap, tak je to přesně určená část disku, dokonce souvislá (pokud disk neusoudí, že je nějaký ze sektor vadný a nepřemapuje ho na náhradní). Když totéž udělám na SSD, tak se to sice navenek tváří stejně, ale interně je tomu nepochybně úplně jinak. Protože to by ty SSD odešly dost brzy.

Na pevném disku prostě jde přesně určit, do kterého sektoru se bude zapisovat a taky se tam zapisuje, pokud nedojde k přemapování. Kdyby to na SSD funfovalo stejně, tak se ten jeden sektor dá zničit opakovanými zápisy během pár vteřin. SSD interně rozhazují zápisy po celém disku, pokaždé jinam, aby docházelo k rovnoměrnému opotřebení.

Takže na SSD swap partition nebo swap file na jakémkoliv filesystému i kdyby se na začátku jednalo o souvislou oblast disku, tak po několik zápisech je rozstrkaná po celém disku. A podle mě btrfs pro ten swapfile akorát nevytváří kontrolní součty. A z nějakého důvodu vyžaduje, aby swapfile nebyl na komprimovaném subvolumu.

Mimochodem, dneska jsem si pustil cvičně virtuál Debianu s btrfs (ne na notebooku o kterém se zde píše), zkontroloval jsem, že mám nastavenou kompresi a vytvořil jsem tam swapfile. Pak jsem se snažil, aby se do něj taky něco zapsalo, to se povedlo a po nějaké chvíli jsem provedl scrub. Ten proběhl bez problémů, pouze varování, že se používá swapfile a že tam tedy kontrola neproběhne. Žádné hroucení systému ani filesystému se nekonalo. Bylo to tedy ve virtuálu, takže disk se netvářil jako SSD, mohlo se to chovat jinak. Ale man 5 btrfs striktně píše, že swapfile na komprimovaném subvolumu být nesmí. A pak se v tom vyznej.

[LarryL]

Jo, NOCOW bez komprese jak říká také wiki.

Deaktivuj/vymaž swapfile a proveď znovu opravné kroky, které jsi dělal (scrub atd.), ať víš jestli swapfile je příčinou problémů. Pokud problém nezmizí, tak budeš muset hledat příčinu jinde.

[trekker.dk]

Ale man 5 btrfs striktně píše, že swapfile na komprimovaném subvolumu být nesmí.

Tipnul bych si, že by to mohl být klasický důvod, že aby na takovém souboru bylo možné něco odswapovat, je nejprve potřeba alokovat paměť (kterou ten systém v danou chvíli nemusí mít, proto se swapuje.) Něco podobného, proč se nedoporučuje (nebo přinejmenším nedoporučovalo) mít swap na síťovém disku.

[j]

Blabolis naprostej nesmysl.

Pokud je to soubor, je to soubor jako kazdej jinej, a kernel rohodne v zadnym pripadne nesaha na bloky zarizeni, protoze tim bys celej filesystem rozbil! Vubec nemluve o tom, ze ten soubor nemusi byt ani zarovnanej na velikost bloku. A ani nezminuju prostej fakt, ze kazdej FS je uplne jinak organizovanej, takze by ta tvoje uzasna obsluha swapsouboru musela byt napsana zvlast pro kazdej extra.

Prave proto je mimo jiny swapfile vyrazne pomalejsi nez swap partysna - musi se vyuzivat obsluha fs, coz je rezije navic. A swapfile se vyrabi mimo jiny proto, ze ho snadno muzes vzit a presunout jinam.

2xxl "Na pevném disku prostě jde přesně určit, do kterého sektoru se bude zapisovat" ...

To uz drahne let taky neplati, ackoli ten bordel na disku bude ponekud mensi, tak i na plotnovych discich dochazi naprosto bezne k tomu, ze prave elektronika disku rozhoduje o tom kam se fyzicky co zapise. Pokud sis toho nevsim, tak trebas udaje o poctu ploten/hlavicek/sektoru/... se kteryma pracuje system, uz davno neodpovidaji realite toho kteryho disku. Obchazeli a obchazeji se tak vsemozny omezeni, za tu cenu ze v tom disku mas nejakej preklad na tu realitu, uplne stejne jako u toho ssd. Mno a predevsim soho disky pak obsahujou vsemozny "vylepsatory", ktery se snazej ruzne sibovat datama tak, aby to jakoze bylo rychlejsi (prave firmware disku je casto to jediny, co je jiny u disku do pole, kterej tohle delat nebude).

---

Dete s tim guuglem dopice!

[xxl]

2xxl "Na pevném disku prostě jde přesně určit, do kterého sektoru se bude zapisovat" ...

To uz drahne let taky neplati... Pokud sis toho nevsim, tak trebas udaje o poctu ploten/hlavicek/sektoru/... se kteryma pracuje system, uz davno neodpovidaji realite

To jsem si všiml, ale pořád jsem předpokládal, že když například pomocí dd zapíšu do sektoru N, a udělám to opakovaně, tak disk zapíše pokaždé do stejného fyzického sektoru.

Jak tedy funguje badblocks? Ten také snad předpokládá, že když zapíše několikrát různý vzorek na jeden sektor, tak že ten sektor není pokaždé jiný.

[trekker.dk]

Sektor, který vidí všechno mimo ten disk (tj. operační systém), je vždycky stejný. Zapíšete tam data, přečtete odtud data. Je jedno, jestli to dělá filesystém, badblocks, beztak to vždycky skončí tím, že to v kernelu vyřídí obsluha blokových zařízení. Kdysi dávno ta pozice, kterou jste si řekl, 1:1 odpovídala pozici na tom disku. Dneska to tak není, kam se to reálně fyzicky propíše, to se nedozvíte, pokud nemáte přístup k low-level nástrojům od výrobce.

Vy víte pouze to, že pokud si od disku řeknete o data na pozici X, tak se ten požadavek obslouží vždycky ze stejného fyzického prostoru. Pokud řeknete o zápis na pozici X, tak se to možná obslouží ze stejného prostoru, možná se to zapíše jinam. Garance je (měla by být) pouze taková, že pokud data někam zapíšete z pohledu uživatele toho disku, tak všechna následná čtení z toho místa budou obsloužena ze stejného fyzického prostoru, nebo se vrátí chyba.

Tj. badblocks, pokud několikrát zapíše to samé na jeden sektor, tak fyzicky se na tom disku může zapsat pokaždé na jeden sektor, ale taky nemusí.

[trekker.dk]

tak všechna následná čtení z toho místa budou obsloužena ze stejného fyzického prostoru, nebo se vrátí chyba

A vlastně ani to ne. Ten disk se v mezičase může rozhodnout, že to fyzické místo využije jinak, takže ta data přemístí a zatímco vy pořád čtete z toho samého (ze svého pohledu) místa, tak fyzicky se čte odjinud než posledně.

[xxl]

Pokud HDD používá pro zápis na sektor X ještě jiné rozhodování než to, že sektor byl dříve vyhodnocen jako vadný (a přemapován na sektor Y), tak se chováním začíná podobat SSD.

Nicméně u toho SSD očekávám, že už druhý zápis na sektor číslo X bude fyzicky umístěn jinam, než zápis první, a doufám, že se nemýlím. Protože poslat nějakých 600 zápisů, nebo kolik tak asi jeden sektor na SSD vydrží, na jedno "logické" místo je otázka chvilky. Takže vytvořit vadný SSD, vhodný k reklamaci, by bylo dost jednoduché.

[trekker.dk]

Pokud HDD používá pro zápis na sektor X ještě jiné rozhodování než to, že sektor byl dříve vyhodnocen jako vadný (a přemapován na sektor Y), tak se chováním začíná podobat SSD.

Těžko říct, výrobcům disků do kuchyně nevidíte. Osobně bych ale tomu, že rotující disk bude přemapovávat sektory na základě něčeho jiného, než že jsou vadné, moc nevěřil. Rozhodně ne, dokud to nebude ozdrojováno líp než tvrzením anonyma, u kterého je tu historicky víc než poloviční šance, že jsou věci opačně, než tvrdí.

[PetebLazar]

Očekával bych, že k relokaci sektoru vnitřní logikou HDD do rezervní oblasti dojde na základě fyzického čtení signálu (nízká úroveň signálu či míry chybovosti). Sektor může být datově stále čitelný či úspěšně dopočítaný z CRC, ale přesto z pohledu logiky HDD vhodný na relokaci. Celý proces je (v případě úspěšného čtení) počítám před OS transparetně skryt (realokace sektoru bude uložena patrně někde v EEPROM HDD, dnes možná ve flash). U SSD to patrně bude mj. ztráta schopnosti udržet v buňce "zřetelně čitelnou" úroveň napětí pro danou bitovou hodnotu (s počtem bit/cell stále náročnější úkol).

Zajímalo by mne jak je tomu v rámci serverových HDD s limitovaným TLER, ERC, CCTL. Kdy hlavním cílem je v případě nečitelnosti sektoru tuto zprávu odeslat vyšší vrstvé, která situaci vyřeší redundancí například na úrovni RAID. Dopočítávání správné hodnoty sektoru (u desktopových HDD např. až se 7s timeoutem) by při opakovaných intenzivních requestech v problémové oblasti znamenalo prakticky zastavení IO (aplikace).

[pet I.]

Pokud HDD používá pro zápis na sektor X ještě jiné rozhodování než to, že sektor byl dříve vyhodnocen jako vadný (a přemapován na sektor Y), tak se chováním začíná podobat SSD.

Máš na mysli něco jako disky se šindelovým zápisem?

[LarryL]

Blabolis naprostej nesmysl. Pokud je to soubor, je to soubor jako kazdej jinej,

V tom případě bych byl rád abychom si to teď a tady jednou pro vždy ujasnili. Už jsem to jednou vysvětloval Alešovi Kapicovi, že swapfile není soubor jako každý jiný.

V odkazu výše je přímo ocitovaný Andrew Morton, jeden z hlavních vývojářu Kernelu, který o swapfile říká: "The kernel generates a map of swap offset -> disk blocks at swapon time and from then on uses that map to perform swap I/O directly against the underlying disk queue, bypassing all caching, metadata and filesystem code. ". Na druhé straně ty a Kapica tvrdíte opak. Kde je teda pravda?

a kernel rohodne v zadnym pripadne nesaha na bloky zarizeni, protoze tim bys celej filesystem rozbil!

Samozřejmě, že s takovým přímým přístupem musí filesystém počítat - swapfile na Btrfs až do verze kernelu 5 nebyl podporovaný. Viz brtfs wiki.

Prave proto je mimo jiny swapfile vyrazne pomalejsi nez swap partysna - musi se vyuzivat obsluha fs, coz je rezije navic. A swapfile se vyrabi mimo jiny proto, ze ho snadno muzes vzit a presunout jinam.

Hele, nejseš přeslečenej Kapica? Protože přesně tyto bludy valil i on v té předchozí diskuzi a zcela to odporuje tomu co napsal Andrew Morton. Bez urážky, ale budu se víc řídit tím co řekl vývojář kernelu než anonym v diskuzi.

Takže teď se všichni uklidníme a čekám na věcné protiargumenty o swapfile a doufám, že to znovu nevyšumí do prázdna, a zjistíme že i o swapfile nejak ta pravda je

[Aleš Kapica]

Když už ses teda rozhodl o mne navážet, tak bych tě rád upozornil, že ta odpověď co ti poslal Andrew Morton rozhodně neznamená, že je vyloučeno aby u COW nedošlo k rozesrání FS.

[LarryL]

Nenavážím se, ale v tom předchozím vlákně jsi dost intenzivně vysvětloval že u swapfile se swapuje do souboru v rámci žurnálovacího FS. Takže když Jéčko napsal to samé, tak to vypadalo, že jste jeden a ten samý člověk.

že je vyloučeno aby u COW nedošlo k rozesrání FS.

Nevím co tím myslíš, ale jde o to, že swapfile obchází filesystém a swapfile neznamená větší zatížení pro systém než swap oddíl. To bylo předmětem sporu v předchozí diskuzi.

[Aleš Kapica]

Tak tos evidentně blbě pochopil. Nehovořil jsem o žurnálovacím FS (to je i ext4), ale o COW FS – konkrétně o swapování do souboru na Btrfs.

Nevím co tím myslíš, ale jde o to, že swapfile obchází filesystém a swapfile neznamená větší zatížení pro systém než swap oddíl. To bylo předmětem sporu v předchozí diskuzi.

Swapovací soubor možná obchází FS, ale pokud se svapuje do souboru, který nemá atribut nocow, a nemá předem nastavenou velikost, musí logicky nastat problém.

Konkrétně. Kdy začíná systém swapowat? Když mu dochází paměť. Jenže je-li swap na cow systému, který neustále převaluje data, vstupují do toho další IO operace a ty také chtějí nějakou paměť. A výsledek je, že to všechno vytuhne. Ne na furt, ale na dlouho. Normálně to možná takovou zátěž nepřináší, protože si to řídí jádro. Ale pokud do toho kecá ještě win virtuál, který TAKÉ swapuje do souboru. No tak to už problém podle mne je.

[Heron]

Když se tady tak intenzivně řeší swap, to fakt někdo používáte v produkci? Měl jsem rozepsaný článek o swapu jako o dalším mýtu, který se drží ve světě IT a ke kterému nikdo nemá řádné vysvětlení. Při přechodu na FreeBSD jsem nejprve nechal instalátor swap vytvořit (protože se všude psalo, že je to nutnost, bez toho to nepojede - i když jsem si o tom myslel svoje), potom jsem swap zrušil a všechno jede (jak by taky ne). Když jsem i z podnětu této diskuse hledal aktuální doporučení ohledně swapu, tak jsem našel komické diskuse, kde se někdo ptá, jestli je swap potřeba, na to mu někdo odpoví 2xRAM, dotyčný se zeptá, že tak velký disk ani nemá (protože na 64GB systémovém ssdčku se dost blbě vytváří 256GB swap oddíl) tak mu poradili, že alespoň nějaký swap by měl mít, protože prostě proto. (Magické myšlení. Swap tam je jen pro dobrý pocit. Dělalo se to tak vždycky.) Na linuxu swap (a v produkci nikdy) nepoužívám 15 let, na FreeBSD od první testovací instalace (2015) taky ne. Vše samozřejmě funguje.

Chápu použití swapu pro speciální příležitosti, kdy nelze z HW důvodů přidat paměť a pro občasné operace se swap hodí, ale na normálním produkčním serveru fakt ne. Na vmku už vůbec ne, protože tam to zabije diskové io i pro další servery.

Swapfile a ještě na btrfs - vlastně mě překvapuje, že se to vůbec řeší. Proč to teda používáte? Máte k tomu nějaký speciální důvod? (Otázka do pléna, ne jen na Aleše.)

[Josef Kufner]

Já celkem nedávno měl na serveru swap kvůli tomu, že se mi nedařilo sehnat kompatibilní paměť (a zbytek hardwaru je letitý a spolehlivý). Tak jsem tam strčil malé SSD a na polovině udělal swapovací oddíl. Docela to pomohlo. Pak jsem nějakou paměť našel a potřeboval jsem na chvíli další SATA port, tak jsem swap odpojil a už ho nějak nezapojil.

V případě notebooku je dobré swap mít kvůli uspávání na disk.

Další rozumný důvod ke swapu je, že se tam odloží nepoužívané či málo používané kusy zaplácané paměti nějakým nevychovaným, ale potřebným procesem.

[trekker.dk]

Když se tady tak intenzivně řeší swap, to fakt někdo používáte v produkci?

Pokud jako produkci považujeme pracovní stanici tak jo. Pro uspání na disk.

protože prostě proto

Programy, co dlouhodobě neběží - ale můžou se probudit a chtít něco dělat - je vhodnější odswapovat a uvolnit tím paměť pro něco jiného. Samozřejmě na stroji, co jde s RAM do desítek až stovek GB, je to skutečně jen pro ten dobrý pocit.

Na vmku už vůbec ne, protože tam to zabije diskové io i pro další servery.

V případě výše nezabije.

[Heron]

Programy, co dlouhodobě neběží - ale můžou se probudit a chtít něco dělat - je vhodnější odswapovat a uvolnit tím paměť pro něco jiného.

Jo, tohle je také jediné legitimní použití, které jsem v praxi viděl (krom nemožnosti přidat další paměť). Pokud nějaký stroj má různou zátěž dle denní doby, tak to lze chápat. Ale stejně je lepší, aby ty služby běžely třeba jen na požádání (jako závislosti jiných služeb, nebo socket activation apod.).

Jako moc skutečných použití se asi nenajde. V diskusích jsem žádné nenašel. Instalátory tvrdošíjně nastavují swap dle velikosti ram, některé "alespoň" 2GB (takže se to dá chápat jako postoj autorů dané distribuce). U desktopu to může mít význam z hlediska uspávání - ale to asi ne každý využije, hodila by se anketa, kolik lidí uspává desktop / stanici.

[Max]

Používám u VM čistě jako něco, co mi dá chvilku čas v případě problému. Všude jedu "vm.swappiness = 10". Jediné, kde swap nepoužívám, je storage nad freebsd. Ač to TrueNAS striktně doporučuje, má zkušenost je nepoužívat a člověk se pak vyvaruje problémům.
Zdar Max

[Heron]

Používám u VM čistě jako něco, co mi dá chvilku čas v případě problému.

A jak to funguje v praxi? Máš tam 64GB swap, nic se neděje, monitoring zelenej a najednou se začne používat swap a ty víš, že máš problém a ten swap ti dá čas? Jak se to stane? Když by něco žralo paměť postupně, tak to vidíš. Když se nějaký proces zblázní a alokuje si naráz 2TB RAM a začne se okamžitě plnit swap, tak už s tím stejně nic neuděláš. (A v případě bez swapu už by ho zastřelil oomk a s trochou štěstí nic jiného.) Ptám se vážně.

Viděl jsem mnoho provozů, kde to bylo "akceptovatelně špatně", tj bylo málo paměti, hw nedovoloval přidat další. Ok, dejme tomu.

Potom hodně provozů s divnou velikostí paměti (6GB apod.) a k tomu swap, protože to nějak jede a byla velká neochota (tj šlo by to, ale někdo řekl ne - klasická žába na prameni, spoustu věcí by to zrychlilo, ale prostě ne) přidat normální velikost ram (tj třeba 16GB). To nepovažuju za akceptovatelné.

A je to celkem zajímavé kritérium i pro výběr VPS, kde někde mají template se swapem a jinde prostě by default není. A je celkem sranda, že tam, kde není swap v template, mají současně i o dost rychlejší storage (takže by se na něj klidně dalo swapovat), než tam vedle - což je známka šetření na HW, kde se jen dá - málo paměti, pomalý storage. Mám nové vmko v zahraničí a by default 30tis iops. Ani jsem se o to neprosil. Tady v ČR má zákazník VMko, platí za něj nehorázné peníze a milostivě mu zvýšili limit na iops na něco jako směšných 5000 ze směsných 1000 a chtějí za to příplatek.

A toto potom deformuje nastavení těch serverů. Trochu mi to připomíná doby, kdy telecom účtoval 10tis Kč za 64kbps, zatímco jiní už jeli na megabitu.

[Josef Kufner]

Spíš bych si tipnul, že tam, kde swap ve výchozím stavu není, ten storage prostě není tolik vytížen a proto jede rychleji.

[Heron]

Ano, toto je pravda, ale současně je to také dáno tím, že ty vm mají obecně více paměti (a žádnou jinou možnost, pokud dojde).

[Max]

Funguje to tak, že swap je vesměs stále prázdný. Že by se nějaký proces zbláznil a zalokoval něco víc, to se nestává. Pokud ale dojde k nějaké neobvyklé události jednou za rok, tak swap mi zajistí, že ta app zůstane up. Tou událostí jsou různé penetrační testy z třetí strany apod. Na základě nich pak upravuji jednak fw, nebo i velikost ram apod. Jinak si tedy i monitoringem hlídám, aby swap byl prázdný a nepoužíval.
A pak tu jsou služby, které by design vyžadují swap. Tj. Windows, OracleDB apod. Nicméně i u toho Oracle se snažím, aby na swap nesahal a mám v něm nastavený takový memory management, aby fakt neswapoval.
Zdar Max

[MP]

Jo pouzivam vsude. A casto se vyuzije. Treba tenhle tyden na nekolika dedikovanych web (nginx+php+redis) VM se mi do swapu dokonce nacpal cely obsah redisu (samozrejme kvuli nejakemu php). Ty VM maji 4GB RAM.

Ono je to jako s kontejnery. Kdyz jich ma clovek desitky/stovky a vice, tak alokovat jim 16GB je casto neekonomicke. Nemluve o tom, ze kdyz se to pak sesype v clusteru a sluzby zacnou migrovat jinam, tak takove mnozstvi pameti ani hypervizory nenaalokuji a sluzby realne umrou.

[Heron]

To je celkem fajn u in-memory databáze... (On si to neoznačí mlockem?)

[j]

Swap te nic nestoji ... disku mas vetsinou mnohem vic nez potrebujes, takze to je prvni vec na tema a proc ne. Druha vec jsou nejaky mimoradnosti, kdy je to proste rekneme 10%+ na tema "jeste to pobezi". Ve skutecnosti si kazdej system kdyz mu ten swap das neco malo odlozi, radove to muzou byt desitky, max stovky MB, ale lepsi nez dratem do oka.

Mam trebas swap na sambashare, a tam se tim uvolni neco malo pro cache.

Mno dalsi aspekt pak jsou extra appky extradementnich vyvojaru, ktery se bez swapu odmitaji spustit. Typicky zcela bez ohledu na dostupnou ram.

Dotretice, kampak bys chtel uspavat notes?

A ve finale, typicky distro ti pri instalaci alabfu ten swap vyrobi.

---

Dete s tim guuglem dopice!

[Heron]

Swap te nic nestoji

Ne? Není to tak dlouho, kdy ceny skutečně rychlých ssd (ne jen hračky na doma) byly tak vysoko a kupovaly se (pro různé zfs metadata cache apod.) takové kapacity, že to bylo menší než velikost systémové paměti. Serverů s 64GB systémovým SSD a 256GB RAM jsem viděl několik. Storage je na poli nebo na interních hdd.

Ve skutecnosti si kazdej system kdyz mu ten swap das neco malo odlozi, radove to muzou byt desitky, max stovky MB, ale lepsi nez dratem do oka.

Ještě se mi to nestalo. Teď jsem ze srandy dal swap na několik interních serverů (abych viděl) a stále nula.

Mam trebas swap na sambashare, a tam se tim uvolni neco malo pro cache.

Co přesně by se na samba serveru mělo dát do swapu a jak moc paměti to uvolní? To sshčko? Aktivované socketem?

Mno dalsi aspekt pak jsou extra appky extradementnich vyvojaru, ktery se bez swapu odmitaji spustit. Typicky zcela bez ohledu na dostupnou ram.

S tím jsem se ještě nesetkal (a často o tom slyším). Kdybych se s tím setkal, tak to stejně nepůjde na moje servery.

Dotretice, kampak bys chtel uspavat notes?

Notes neuspávám, nepoužívám (pouze z donucení), bavíme se o serverech.

A ve finale, typicky distro ti pri instalaci alabfu ten swap vyrobi.

Ano, a nikde k tomu nenajdeš nějakou smysluplnou dokumentaci. Jen mě Deb pokaždé seřve, že tam nemám swap a že to vybuchne, když tam nebude. (Nehledě na to, že od něj asi odejdu, protože mě už fakt jebe, že minimální instalace na serveru, kde nedávám ani standard system utilites, se instalují věci jako bluetooth, wpa supplicant apod. a jako trolling task-laptop. Minimální instalaci bez grafiky fakt všichni běžně asi dávají na laptop.)

[trekker.dk]

minimální instalace na serveru, kde nedávám ani standard system utilites, se instalují věci jako bluetooth, wpa supplicant apod. a jako trolling task-laptop

patche vítány

[Heron]

Čekal jsem to

Mám na to preseed a následnej ansible, takže to jde rychle, ale ten default je prostě připraven na desktop / laptop. Zcela tam chybí varianta něco jako "minimal-server" nebo i "minimal-container" (jasně, debootstrap).

[trekker.dk]

Co si budeme povídat, ten instalátor je dělaný s tím, že se Debian snaží naprosto nesmyslně zalíbit uživatelům desktopů s minimem zkušeností.

[LarryL]

Jenže je-li swap na cow systému

Jenže swapfile nemůže být na COW systému. Pokud se bavíme o Btrfs, tak kernel to neumožní:

+ if (!(BTRFS_I(inode)->flags & BTRFS_INODE_NODATACOW)) {

+ btrfs_warn(fs_info, "swapfile must not be copy-on-write");

+ return -EINVAL;

Je to vymyšlené tak, že FS nekecá kernelu do jeho swapfile.

No tak to už problém podle mne je.

Není. Problém je to jen ten, že se pro dvě diskové operace (swapování hosta a swapování hostitele) používá jeden disk), ale stejně tak by to bylo, kdybys měl swap partišnu na stejném disku jako máš virtuálku widlí.

[xxl]

Jenže swapfile nemůže být na COW systému. Pokud se bavíme o Btrfs, tak... kernel to neumožní

No já nevím. Mně to kernel asi umožnil. Sice jsem se snažil, aby subvolume /swap, na kterém jsem měl swapfile, byl připojený jako nocow, ale protože první se připojil /rootfs, který byl cow, tak cow byl i /swap. A na tom jsem bez problémů vytvořil a aktivoval swapfile. Ten jsem měl pro jistotu přímo vytvořený jako nocow a lsattr tvrdil, že nocow je. Jak to bylo ve skutečnosti, netuším.

[LarryL]

A na tom jsem bez problémů vytvořil a aktivoval swapfile. Ten jsem měl pro jistotu přímo vytvořený jako nocow a lsattr tvrdil, že nocow je.

Tak pak nemáš důvod si myslet, že swapfile byl COW.

[LarryL]

...tak co Jéčko, chceš to přejít mlčením? Výše v diskuzi jsi mě opravil když jsem chybně napsal, že COW se neprovádí nad jednotlivými soubory, ale nad bloky a já sem neměl problém svůj omyl přiznat. Máš i ty dostatek odvahy přiznat, že jsi se ohledně swapfile spletl a že swapfile není soubor jako každý jiný? Souhlasíš, že swapfile funguje, tak jak popsal Andrew Morton?

[j]

Mel by sis soudruhu nejdriv precist neco o tom, jak veci fungujou, a pak mozna jit nekam o necem diskutovat, Nebyl bys za uplnyho vola.

Krome fs, muzou byt na disku dalsi vrstvy, a ten tvuj system, kterej si zjevne vubec nepochopil, by je rozbil uplne vsechny. Disk muze byt sifrovany, muze tam byt raid, muze tam byt lvm ... a to vse v libovolnym poradi.

Tudiz trvam na tom ze to funguje jak funguje, swapfile muze byt na zcela libovolnym FS, jen se z duvodu nehezkyho vykonu nektery varianty nedoporucuje pouzivat. A je to soubor jako kazdy jiny, prave to je jeho nejzasadnejsi vlastnost, a defakto jediny plus === da se libovolne presunovat mezi diskama a klidne i ruznejma fs.

---

Dete s tim guuglem dopice!

[LarryL]

Mel by sis soudruhu nejdriv precist neco o tom, jak veci fungujou, a pak mozna jit nekam o necem diskutovat, Nebyl bys za uplnyho vola.

Jestli jsem soudruh, tak ty jsi soudružka, která má své dny. Nepiš o tvých emocích, ale piš protiargumenty na diskutované téma. Zatím jsi za vola ty.

Krome fs, muzou byt na disku dalsi vrstvy, a ten tvuj system, kterej si zjevne vubec nepochopil, by je rozbil uplne vsechny. Disk muze byt sifrovany, muze tam byt raid, muze tam byt lvm ... a to vse v libovolnym poradi.

A co jako? Swap i swapfile se dá šifrovat viz např. Archwiki. Kernel obchází kód FS i LVM, protože kernel přistupuje na swap i swapfile přímo. Čemu na tom nerozumíš? Na LVM2 se dá jednoduše vytvořit swap i swapfile. Ohledně RAIDu: "You can set up RAID in a swap file on a filesystem on your RAID device, or you can set up a RAID device as a swap partition, as you see fit. As usual, the RAID device is just a block device."

Jaké další informace ke swapfile ještě potřebuješ dohledat? Co ti na tom ještě pořád není jasné? Mně se systém nerozbil, ale pokud se rozbil tobě, tak dej dotaz do poradny, abychom zjistili co jsi při práci se swapfile udělal blbě.

swapfile muze byt na zcela libovolnym FS

Ne nemůže. Už jsem tady o tom psal. Např. na BTRFS je podporován až od kernelu 5.0. Máš to napsané o 4 příspěvky výše včetně odkazu na zdroják. Další odkaz na btrfs wiki. Pokud nevěříš webům, tak přímo v man swapon se píše: "The swap file implementation in the kernel expects to be able to write to the file directly, without the assistance of the filesystem. This is a problem on files with holes or on copy-on-write files on filesystems like Btrfs."

A je to soubor jako kazdy jiny,

Není a kdyby tě zajímalo kdy přesně se z obyčejného souboru stává swapfile, tak je to po příkazu # swapon /swapfile.

jen se z duvodu nehezkyho vykonu nektery varianty nedoporucuje pouzivat.

Pošli odkaz ať víme o čem mluvíš.

da se libovolne presunovat mezi diskama a klidne i ruznejma fs.

Ne, swapfile se nedá libovolně přesunovat. Musíš nejdříve použít příkaz swapoff. Tím kernel "pustí" swapfile. Až pak můžeš přesunout soubor, který v tu chvíli už není swapfile a pak znovu použít swapon, címž z něj znovu uděláš skutečný swapfile. Pozor: pokud máš nastavené uspávání do swapfile, tak po přesunu musíš upravit kernel parametr resume_offset= v souboru /etc/default/grub.

[j]

Jiste, takze jen potvrzujes, ze ses blb.

Ale jiste mas nejaky ubervysvetleni, jak se pri vyrobe toho souboru zaridi (nijak) aby byl srovnanej na fyzicky bloky zarizeni. Jo aha, on si swap ten blok na kterym je jinej soubor proste prepise ... lol.

Mimochodem, leda blb nevi, ze kazdej normalni otevrenej soubor se neda presunovat. Jakej to zazrak.

---

Dete s tim guuglem dopice!

[LarryL]

Ale jiste mas nejaky ubervysvetleni, jak se pri vyrobe toho souboru zaridi (nijak) aby byl srovnanej na fyzicky bloky zarizeni. Jo aha, on si swap ten blok na kterym je jinej soubor proste prepise

Klidně bychom mohli podiskutovat jak se kernel chová při nezarovnání swap partition nebo swap file a mohli bychom najít u kus zdrojáku, který to řeší, ale nevím proč bych o tom diskutoval s tebou když se chováš jako malý spratek.

Mimochodem, leda blb nevi, ze kazdej normalni otevrenej soubor se neda presunovat. Jakej to zazrak.

Ostatní soubory otevíráš taky tak, že k nim má kernel přímý přístup bez asistence filesystému? Mám tě také oslovovat Blbe? Je ti takový styl komunikace bližší?

[trekker.dk]

Nechápu.

Potenciální vysvětlení: https://www.abclinuxu.cz/blog/Tomik/2021/1/kutilove-meli-pravdu/diskuse#285

(00d64a31970fd5260ab0f29c53d87c5819e57eb75e968837deca08e454776f15)

[xxl]

Nový vývoj.

Proběhla kompletní reinstalace/obnovení dat na disku. Všechno zatím fungovalo/funguje (pozn. na btrfs je kromě efi všechno, tj. i rootfs).

Ráno jsem provedl btrfs scrub. A ejhle. 5 chyb, žádné konkrétní soubory nenahlášeny. Příklad:

BTRFS error (device sda2): unable to fixup (regular) error at logical 525389164544 on dev /dev/sda2

Vypnul jsem to. Pak jsem provedl btrfs check --readonly --check-data-csum. Zase 5 chyb typu:

mirror 1 bytenr 525389164544 csum 4 expected csum 142

Žádné konkrétní soubory nenahlášeny. Opakovaný check nahlásil úplně stejné výsledky.

Při testech hardware dodal data i metadata (žádná hw chyba), ale nesedí jejich porovnání, takže btrfs hlásí chybu. Zatím snad jen v datové strukruře, ne v souborech. Počet chyb při scrubu i checku je stejný (a předtím taky býval), tj. k vytvoření chyby dochází/došlo spíš při zápisu dat, než při jejich čtení.

Dál mě ovšem nic nenapadá.

[j]

A krome toho vseho co tu pises, zkousel si ten disk dat do jinyho stroje? Protoze krome spousty jinych veci, trebas se proste nesnese s deskou.

Vzhledem k tomu ze je to SSDcko to ovsem ma vsechny priznaky chcipajiciho SSD. Pripadne se poohlidni, jestli pro to SSDcko neni firmware.

---

Dete s tim guuglem dopice!

[LarryL]

A krome toho vseho co tu pises, zkousel si ten disk dat do jinyho stroje? Protoze krome spousty jinych veci, trebas se proste nesnese s deskou.

Tazatel má kombinaci AMD a Samsung SSD 870 EVO. Takže by stálo za prozkoumání zda tato problémová kombinace již byla v kernelu/firmware vyřešena.

[Andrej]

Taky mě nenapadá nic jiného než

• zkusit tentýž disk v jiném stroji nebo
• zkusit jiný disk (ať už kus nebo typ) v tomtéž stroji.

[.-]

nebo zkusit ext4

[Andrej]

Myslíš tamtu sračku z 20. století, která ztrácí data?

[trekker.dk]

Pouze ve vašem světě. U nás ostatních neztrácí.

[Andrej]

A takhle to vypadá, když má někdo náhodně posraná data, neví o tom a ještě se tím chlubí.

Kdyby blbost kvetla… Jenže ona spíš smrdí jako hovno.

[port666]

Hele, ze ty nemas babu?

[trekker.dk]

Náhodně rozbitá data nemám, děkuji za optání. Kdybych měl, tak to poznám. Není těžké rozlišit, když někde něco není tak, jak to původně bylo. Aspoň pro některé z nás.

[LarryL]

V tom případě se musím přiznat, že patřím k těm co u ext4 (bez zálohy a bez RAIDu) nepoznám jak to původně bylo. Teď se mi stala taková nemilá věc. HDD ve SMARTu hlásil navýšenou hodnotu u 197 Current_Pending_Sector tak jsem spustil # smartctl -t short /dev/sdb a následně # smartctl -t long /dev/sdb

Ani jeden nedoběhl, skončily na 90%:

#17 Extended offline Completed: read failure 90% 26658 3812013896

#18 Short offline Completed: read failure 90% 26658 3812013896

Podle posledního čísla LBA jsem vypátral, že je to sektor uprostřed souboru image disku VM, který pro mne nebyl nijak důležitý, takže nebyla záloha, ale říkal jsem si, že vytváření VM by mi zabralo čas, tak jsem soubor pomocí příkazu ddrescue zachránil a VM normálně fungovala. Pointa příběhu je, že žádné checksumy nemám (protože ext4), takže nemám tušení jestli ty vadné sektory byly prázdné nebo na nich něco bylo a tudíž mi disk nějaké data ztratil.

[trekker.dk]

To se mi nezdá jako případ "neví o tom"

[LarryL]

Vím o HW problému, ale nevím zda jsem přišel o data. VM funguje, možná byly vadné sektory v místě kde nic nebylo, možná se problém projeví až ve VM spustím nějakou aplikaci a ta nahlásí poškozený/chybějící soubor, možná si to OS uvnitř image disku opravil sám. Kdyby jen "přeskočily bity" na nějakém sektoru a nevzniknul HW problém, který by znemožnil čtení sektoru, tak bych se to asi nikdy nijak nedozvěděl. VM by fungovala a kdyby se objevila modrá smrt, tak bych nadával na Billa a neměl bych tušení, že za to může HDD, který neudržel data. Pokud jsem teda nepřehlédl něco jak u ext4 takové "přeskočení bitů" poznat.

[trekker.dk]

Vím o HW problému, ale nevím zda jsem přišel o data.

Checksum ve filesystému ovšem není to jediné a ani nejlepší řešení, jak to zjistit. Pokud vás to skutečně zajímá, máte zálohy.

[JMP]

ono ani zálohování není všespásné, protože ani to nepozná poškozeninu na zdroji a pokud vám zůstanou v zálohách jen poškozeniny, tak jste tam taky...

[trekker.dk]

Zkusil jste si přečíst víc než jeden příspěvek, než jste reagoval?

[Heron]

Trochu tu chybí výpisy z klasických logů, tj dmesg, obecný journalctl (ne jen btrfs) apod. Ne všechny chyby disku se zapíší do smartu.

Zrovna dneska jsme narazili na zbrusu nový disk (ADATA) a po čerstvé instalaci debu(10) začal do dmesgu sypat chyby elektroniky / řadiče / kabelu - (DRDY error).

[xxl]

Příloha:

• log.txt (85438 bytů)

Nic takového tam není a nebylo. To by bylo moc jednoduché.

# journalctl --no-hostname --root /mnt/ssd/@rootfs_bullseye/ --boot _TRANSPORT=kernel --priority=warning

Výpis přiložen.

[xxl]

sry, --priority je info

[Heron]

Trochu mě tam dráždí ten swapfile, to dělá instalátor sám, nebo je to nějaký trolling?

[xxl]

Ne to nedělá instalátor, to jsem udělal osobně já ručně

[xxl]

Ty jsi na to patrně káp.

Přehlédl jsem, že mount option compress se aplikuje na celý filesystém podle prvního připojeného subvolumu, ať si ve fstabu u těch dalších píšeš, co chceš. Takže jsem měl vytvořený swapfile na komprimovaném subvolumu . Naštěstí se vzhledem k dostatku paměti používal naprosto minimálně.

A nejhorší na tom je, že si teď vzpomínám, že jsem si tenhle problém uvědomil, když jsem si plánoval, jak nastavit rozdělení disku a plánoval subvolumy někdy už tak před čtvrt rokem, ale když přišlo na věc, už jsem si nevzpomněl. Skleróza jak vyšitá.

Opravím to a tipuji, že bude po chybách. Každopádně díky.

[trekker.dk]

A je vůbec nějaký důvod mít swapovací soubor místo oddílu?

[Want]

Není, ale jsou obskurní distribuce, které se na to při instalaci neptají a dělají ho tak automaticky.

[xxl]

Tak jsem asi před měsícem nainstaloval k tomu prvnímu disku ještě jeden. Překonfiguroval jsem to na btrfs raid1. Swap jsem dal na samostatné partition - on se skoro nepoužívá, ale je tam.

Notebook normálně používám, ale mnohem častěji (než se doporučuje) kontroluji filesystém pomocí scrubu. Od té doby se žádné problémy neobjevily, ale díky tomu raidu mám klidnější spaní.

PS: zálohy mám taky

[Aleš Kapica]

Mám to řadu let zrovna tak. Na každém z těch disků mám swap, který se použije buď když nestačí 16GB RAM, nebo když ten notebook uspím na disk.

[Josef Kufner]

Moje zkušenost s BTRFS je, že funguje dobře když má nějakou redundanci pro případné opravy, neboť když neumí chyby opravit, tak se chová tak nějak ošklivě a i když data neztratí, tak se těžko opravuje. Hloupější filesystémy jsou v tomto směru lepší, neboť se spíš udrží v provozu, i když obsahují chyby.

[Aleš Kapica]

…, neboť když neumí chyby opravit, tak se chová tak nějak ošklivě

No, ona je to věc názoru. Někdo preferuje strategii „zachránit alespoň něco”, kdežto jiný zase „než aby se vloudila mezi data chyba, tož raději nic”. A vývojáři Btrfs jsou tou druhou cestou.

A v konečném výsledku je to správně, protože se uživatelé mají chovat zodpovědně, neškudlit za každou cenu a zajistit, aby byla pokud možno někde alespoň jedna zdravá, nepoškozená kopie datového bloku, která může nahradit tu poškozenou.

Pro škudlílky jsou jiné typy FS. Akorát se děsně diví, že když pak brečí že mají poškozená data, proč jim místo vyjádření soustrasti škodolibě strouhám mrkev.

[Josef Kufner]

Spíš jde o to, jak se to chová v degradovaném režimu. Nebo když se nepovede jeden blok načíst (např. kvůli vadnému kabelu či po realokaci sektoru), tak místo toho, aby filesystém řekl "tady ten kus chybí" a já mohl ten kousek obnovit ze zálohy, tak přestane celý pracovat a nevratně přepne do read-only, v horším případě se odmítne namountovat úplně a data se musí vytáhnout pomocí btrfs restore.

[xxl]

Btrfs už přece umožňuje opakované rw připojení filesystému v degradovaném režimu.

Vyzkoušel jsem si to. Cvičně jsem vytvořil VM se dvěma disky a btrfs raid1-em, na kterém bylo všechno včetně rootfs. Poté jsem odpojil jeden disk. Systém nenaběhl a hlásil, že nemá druhý disk. Disk jsem mu nedal, ale rebootoval jsem do degradovaného režimu. Všechno fungovalo. To jsem provedl opakovaně a zapsal jsem nějaká ta data na ten jediný připojený disk. Poté jsem znovu připojil ten druhý disk. Naběhlo to bez problémů. Scrub nahlásil chyby, ale opravil je a při druhém spuštění už byl spokojený, bez chyb.

Na běžném filesystému by to také nějak fungovalo, ale už jsem nabyl dojmu, že btrfs mi dává při skutečném problému vyšší šance na vyváznutí bez ztráty dat.

[Josef Kufner]

To vypadá jako příjemná novinka. Od jaké verze to je? Ještě nedávno mi tento scénář neprošel.

[Heron]

Několik let stará novinka. Přesný rok nevím, řešilo se to tu. Mě tohle nějak kompletně minulo, ale asi to bylo v nějakém LTS jádře nebo v nějakém LTS distru. Stručný příběh je, že dřív se to chovalo korektně (už v roce 2011), potom se tam zavedla tato vlastnost a potom to opět odstranili.

[LarryL]

místo toho, aby filesystém řekl "tady ten kus chybí" a já mohl ten kousek obnovit ze zálohy, tak přestane celý pracovat a nevratně přepne do read-only

Ext4 se taky umí přepnout do read-only. Když se mi stala nemilá věc s vadným sektorem, tak asi při pokusu o zápis do vadného sektoru se mi celý disk s ext4 přepl do read-only.

[Aleš Kapica]

Ve skutečnosti je to s ext4 ještě horší, protože pokud si toho nikdo nevšimne dřív, než se takový stroj otočí, jsou veškerá data, která po tu dobu visela v RAM, v prdeli.

[Heron]

Chování při chybě FS se dá nastavit parametrem mountu. Dříve bylo zvykem nastavovat na panic, tj se o chybě vědělo okamžitě, dneska readonly.

errors={continue|remount-ro|panic}

[Aleš Kapica]

Faktem je, že málokoho napadne před restartem zkontrolovat, jestli disk náhodou není ve stavu read-only. Zato když se stroj zničeho nic otočí, každý zbystří.

[Josef Kufner]

Read-only disk se pozná podle nefungujících služeb vcelku rychle.

[Aleš Kapica]

Bohužel někdy ne. Pokud se to přepne za běhu, tak to zůstává v cache. Necucám z prstu, konkrétní situace před mnoha lety.

[Heron]

Já teda pokaždé zjisťuju, proč přestaly ty služby běžet. Je důležité najít příčinu a potom tomu lépe předcházet. Rebootem stroje, v naději, že to samo opraví, se o ta cenná data přijde. Nic se samo neopraví.

Navíc někteří klienti stav serveru rádi vykecají:

PSQL client
psql: error: could not connect to server: Read-only file system

Muj program: spuštěný z jiného stroje v síti:
$ job list
2021/09/20 20:23:13 DB Open Error: pq: could not open file "global/42140": Read-only file system

To znamená, že to uvidíš třeba v monitoringu služeb.

[Heron]

jsou v tomto směru lepší

To je otázka.

Teď jsem narazil na chybu ZFS, kdy jeden soubor nešel otevřít. Ani jako root, nijak. Kouknul jsem se do zpool status a tam 1 chyba CSUM přes všechny disky. Je jasné, že ty disky nejsou vadné a chyba vznikla jinde. zpool mi poctivě napsal, který soubor je vadný. Smazal jsem jej, protože jsem ho měl ještě jinde. Chyba v zpool stále:

 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.

Na stránkách openzfs jsou ještě přísnější, tak rovnou chtějí obnovit celý pool ze zálohy.

Je to prostě vlastnost. FS oznámil pro něj neopravitelnou chybu a upozorní na to admina. Za mě lepší, než tu chybu skrývat a jet dál.

[Josef Kufner]

O skrývání chyb vůbec nejde. Je naprosto v pořádku, že je chyba detekována a oznámena. Jde o způsob a možnosti opravy. Varianta, kdy mi filesystém dá seznam souborů, které jsou poškozené a musím je vytáhnout ze zálohy či vědomě zahodit, a zbytek uvede do konzistentního stavu je zcela vyhovující. Pokud by to byly dočasné soubory, tak je můžu prostě smazat a nechat vygenerovat znovu. Je zbytečné obnovovat celý filesystém.

[Heron]

No jenže kde tento luxus nahlášení chyby včetně jména souboru máš? Právě jen u btrfs nebo zfs. Btrfs je happy, když tam má víc disků a může udělat opravu. ZFS ti rovnou napíše, že ten pool máš udělat znovu. Stěžovat si na to, že btrfs se chová divně na jednom disku, no ok, ale stejně nemáš žádnou lepší alternativu. Navíc když se btrfs na více diskách chová vlastně nejlépe z celé nabídky fs.

[Josef Kufner]

Před pár lety, když mi jeden disk odcházel, tak na ext3 nebo 4 bylo v mc vidět mnoho souborů červenou barvou. Něco jako polámaný symlink, ale u běžného souboru. Nicméně v tomto případě už nebylo moc co opravovat.

Že BTRFS je dnes asi nejlepší volbou, s tím souhlasím, ale nástroje na opravu má jedny z nejslabších, neboť hodně spoléhá na detekci a opravy chyb za běžného provozu (což s redundancí funguje).