On Fri, Nov 07, 2014 at 10:05:05AM +0100, Helge Kreutzmann wrote:
> Package: e2fsprogs
> Version: 1.42.12-1
> Severity: important
>
> Upon boot I saw that a large file system was up for periodic check at
> the next boot. To shorten the next boot time, I umounted the file
> system and wanted to run e2fsck on it as I've done in the past.
> However, e2fsck refuses to do anything, stating:
>
> e2fsck 1.42.12 (29-Aug-2014)
> … is in use.
> e2fsck: Cannot continue, aborting.
What this means is that some program has the device open. E2fsck
tries to open the device using the O_EXCL flag. If the kernel
believes that the kernel is in use somehow (i.e., mounted, or is being
used as half of a /dev/mdX RAID array, or some other userspace progam
has the device open with O_EXCL), then it will return EBUSY.
Try stracing e2fsck, and I think you will see it is the open(2) system
call which is failing. It doesn't fail for me:
<tytso.root@closure> {/}, level 2
577# umount /build
<tytso.root@closure> {/}, level 2
578# e2fsck -f /dev/heap/build
e2fsck 1.42.12 (29-Aug-2014)
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
/dev/heap/build: 128865/2097152 files (2.6% non-contiguous), 4600740/8388608
blocks
So there is something specific with your system that is holding the
device open. This is a feature not a bug; for example, if while the
e2fsck is running in one window, someone else (perhaps another
well-meaning system administrator) tries running e2fsck on the same
device, they will get:
# e2fsck -f /dev/heap/build
e2fsck 1.42.12 (29-Aug-2014)
/dev/heap/build is in use.
e2fsck: Cannot continue, aborting.
If two system administrators were to try running e2fsck on the same
device at the same time, it could result in nasty file system
corruption.
This mechanism (using O_EXCL when opening the device) is also what is
used to prevent a failure mode where a junior intern accidentally ran
mke2fs on half of a RAID1 mirror on an early version of SourceForge.
This was obviously a mistake, although the bigger mistake was made by
the sysadmin who gave root privs to said well-meaning but clueless
intern. :-)
Cheers,
- Ted
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
