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
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
