Re: File with weird permissions, impossible to delete
On Tue, Sep 11, 2018 at 09:21:50PM -0400, Gene Heskett wrote:
> On Tuesday 11 September 2018 19:13:58 Ben Caradoc-Davies wrote:
>
> > On 12/09/2018 00:59, Greg Wooledge wrote:
> > > On Tue, Sep 11, 2018 at 01:52:15PM +0200, Pétùr wrote:
> > >> I have some files, with weird permissions:
> > >> # ls -la
> > >> d-wS--S--T 2 1061270772 2605320832 4096 oct. 7 2412 index.html
> > >
> > > Obvious file system corruption. Unmount, fsck, re-mount, and then
> > > be prepared to restore the data from your last good backup if/when
> > > the fsck failed to repair everything.
> >
> > I would also use journalctl to look for any i/o errors on the affected
> > device.
> >
> > What hardware and kernel and filesystem? ext4 filesystem corruption is
> > rare and usually suggests a hardware fault.
> >
> > I would run a full hardware test, including CPU and RAM, and a long
> > SMART test on the storage if it is capable. SMART self-tests will not
> > usually detect drive data transmission errors caused by cable
> > problems, but the SMART logs should list the CRC error count which can
> > indicate unreliable cables or controller connectors.
> >
> > I would first identify the *cause* and replace all unreliable hardware
> > before bothering to restore from backup. If you have noticed some
> > corruption, you likely also have some unnoticed corruption. Continuing
> > to use unreliable hardware wastes your time and endangers your data.
> >
> > Kind regards,
>
> I will 2nd and 3rd Bens advice. Bad cables have been the huge majority of
> such nefarious goings on. Particularly if they are bright red and 4+
> years old, put a tail on the log, and prod the cable gently with a
> wooden pencil. If the log blows up, bad cable, replace it with any
> color but red. Preferably a month ago...
zfs ftw (although there's still a need for a "read back every block
written, and double check its hash, before committing" which is a
requested feature hopefully soon in the works (for those who can
stomach the ACK latency involved).
zfs is still more certain than everything else available, even
without the above feature.
zfs "scrubbing" (around since dot) gives a time-delay version of this
feature, which is insufficient for the truly paranoid, or for those
struggling with intermittently bad cables.
Good luck,
Here's the feature request, subscribe (or add a heart or thumbs up to
the original post in the thread) to voice your interest:
Verify disks writes #2526
https://github.com/zfsonlinux/zfs/issues/2526
Reply to: