kernel-packages team mailing list archive

[Andy Whitcroft <apw@xxxxxxxxxxxxx>]

I have attempted to reproduce this on both Utopic and Trusty (14.04)
without success, below is a transcript of my attempt on Trusty.  This is
with the latest Trusty main kernel.  Perhaps you could confirm this
script correctly repeats your reproduce steps.  If so then there must be
a system specific component here:

mru@kowtow-t64:~/misc/lp1381961$ sudo ./repro
[sudo] password for mru: 
+ set -e
+ here=/home/mru/misc/lp1381961
+ file=/home/mru/misc/lp1381961/sparse-file
+ loop=/dev/loop7
+ md=/dev/md7
+ mnt=/home/mru/misc/lp1381961/mnt
+ rm -f ''
+ dd if=/dev/zero of=/home/mru/misc/lp1381961/sparse-file bs=1k seek=1024000 count=1
1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 3.9741e-05 s, 25.8 MB/s
+ losetup /dev/loop7 /home/mru/misc/lp1381961/sparse-file
+ mdadm --create /dev/md7 --auto md --level=1 --raid-devices=1 --force /dev/loop7
mdadm: /dev/loop7 appears to be part of a raid array:
    level=raid1 devices=1 ctime=Fri Oct 17 10:32:10 2014
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md7 started.
+ mkfs.ext4 /dev/md7
mke2fs 1.42 (29-Nov-2011)
Discarding device blocks: done                            
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
64000 inodes, 255856 blocks
12792 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=264241152
8 block groups
32768 blocks per group, 32768 fragments per group
8000 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

+ echo '*** before mount ...'
*** before mount ...
+ ls -lash /home/mru/misc/lp1381961/sparse-file
17M -rw-r--r-- 1 root root 1001M Oct 17 10:36 /home/mru/misc/lp1381961/sparse-file
+ mkdir -p /home/mru/misc/lp1381961/mnt
+ mount /dev/md7 /home/mru/misc/lp1381961/mnt
+ cp -rp /etc /home/mru/misc/lp1381961/mnt
+ echo '*** before trim ...'
*** before trim ...
+ ls -lash /home/mru/misc/lp1381961/sparse-file
17M -rw-r--r-- 1 root root 1001M Oct 17 10:36 /home/mru/misc/lp1381961/sparse-file
+ fstrim -v /home/mru/misc/lp1381961/mnt
/home/mru/misc/lp1381961/mnt: 1011752960 bytes were trimmed
+ echo '*** after trim ...'
*** after trim ...
+ ls -lash /home/mru/misc/lp1381961/sparse-file
17M -rw-r--r-- 1 root root 1001M Oct 17 10:36 /home/mru/misc/lp1381961/sparse-file
+ umount /home/mru/misc/lp1381961/mnt
+ echo '*** after umount ...'
*** after umount ...
+ ls -lash /home/mru/misc/lp1381961/sparse-file
31M -rw-r--r-- 1 root root 1001M Oct 17 10:36 /home/mru/misc/lp1381961/sparse-file
+ fsck -v -f /dev/md7
fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

    2718 inodes used (4.25%)
       0 non-contiguous files (0.0%)
       2 non-contiguous directories (0.1%)
         # of inodes with ind/dind/tind blocks: 0/0/0
         Extent depth histogram: 2024
   11814 blocks used (4.62%)
       0 bad blocks
       1 large file

    1621 regular files
     259 directories
       0 character device files
       0 block device files
       0 fifos
       0 links
     829 symbolic links (686 fast symbolic links)
       0 sockets
--------
    2709 files
mru@kowtow-t64:~/misc/lp1381961$

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1381968

Title:
  Fstrim destroys data on loopback device

Status in “linux” package in Ubuntu:
  Confirmed

Bug description:
  I've upgraded Ubuntu Server 12.04 LTS to 14.04 LTS.

  The setup contains a loopback device (/dev/loop3) mounted into a
  software raid 1 (/dev/md2).

  After the weekly cronjob (/etc/cron.weekly/fstrim) ran, I've
  discovered that it wiped all data on the loopback device from the
  raid.

  fstrim-all skips check because the loopback device is part of device mapper raid.
  if [ "${REALDEV#/dev/dm-}" != "$REALDEV" ]; then
          echo "device $DEV is on devmapper, skipping TRIM feature check"

  Issue can be reproduced on raid setup and plain loopback mount setup!

  Here is step-by-step how to reproduce the issue:

  1.) create sparse image file
  dd of=/sparse-file bs=1k seek=1024000

  2.) losetup loopback device
  losetup /dev/loop3 /sparse-file

  3.) create raid1
  mdadm --create /dev/md2 --auto md --level=1 --raid-devices=1 /dev/loop3

  4.) create fs
  mkfs.ext4 /dev/md2

  4.1.) check sparse-file size
  ls -lash /sparse-file

  5.) mount and copy data
  mount /dev/md2 /mnt
  copy some random files on /mnt

  5.1.) check sparse-file size again
  ls -lash /sparse-file -> size indicates it contains the copied data

  6.) destroy loopback via fstrim
  fstrim -v /mnt

  7.) data is wiped
  umount /mnt
  ls -lash /sparse-file -> size indicates that all data is wiped out!
  fsck -v -f /dev/md2 -> will report infinite errors on filesystem

  I could not find any similiar bugreport.

  Best Regards
  Daniel

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1381968/+subscriptions