> >So...I'm going to move everything again to a different portion of my disk
> >(after doing a thorough check of it first), and then redo everything. I
> > found that there are some nifty tools related to repairing XFS
> > partitions, but they can't seem to fix everything. I have, for instance,
> > some things
> >in /lost+found to sort out what they are...
>
> Filesystem checkers (fsck/xfs_repair/etc) put orphaned files and file
> fragments into the lost+found directory for you to go through and
> hopefully identify after a filesystem repair. These checkers are more
> interested in cleaning your filesystem and making metadata "sane" than
> they are about recovering lost data. Some filesystems have repair tools
> that are better at this than others (reisierfs has always been abysmal
> for me. I've had roughly the same luck with e2fsck as I have with
> xfs_repair).
Yeah...so I thought that I wouldn't have to deal with /lost+found files
anymore. I thought journaled fs didn't have that problem...maybe I'm just
naive.
Thanks very much for your insight, Ian. It is most appreciated!
Russell
> >I guess my question is, I don't understand exactly journaling filesystems.
> > I thought that they would save me this kind of trouble. I wonder if I set
> > up XFS the "right" way. I don't know if I want the journal to be on the
> > same disk, or on another, or any of the other options that are available
> > to me.
>
> You generally want an "internal" journal, on the same block device as
> the file data it is journalling writes for. For speed reasons, you may
> consider splitting off an "external" journal to another block device to
> save platter head reads, particularly if you are doing frequent writes
> (think relational database). Honestly, you probably don't want to
> consider anything but an internal journal for your home installation.
>
> >I also don't know if I'm dealing with bugs in the XFS code, which is
> > another thing. I'm using kernel 2.4.26...
>
> I generally try to patch up to the latest XFS stable release I can apply
> to a kernel at the time I'm compiling it. Using development code,
> particularly straight out of CVS, will generally get you into trouble.
>
> Verify the underlying block device. Consider using at least RAID1 to
> protect against drive death.
>
> And the #1 rule to remember regarding data storage: Always backup your
> data.
> - Ian C. Blenke <icblenke@nks.net>
> Networked Knowledge Systems
>
>
> -----------------------------------------------------------------------
> This list is provided as an unmoderated internet service by Networked
> Knowledge Systems (NKS). Views and opinions expressed in messages
> posted are those of the author and do not necessarily reflect the
> official policy or position of NKS or any of its employees.
-- Linux -- the OS for the Renaissance Man ----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 14:23:49 EDT