From: Richard Waterbeek <richardwbb@versatel.nl>
To: linux-xfs@vger.kernel.org
Subject: is there a useful purpose to keep "xfs meta-data" when mkfs.xfs has created a new file system
Date: Thu, 20 Jul 2017 00:25:27 +0000 [thread overview]
Message-ID: <1500510327.1939.36.camel@versatel.nl> (raw)
I wonder, since I have decided to not follow proper advice, that for
example ext2 is meant for a usb removable volume, while journalling fs
aren't [benchmarking wasn't real slow, but I don't seem to appreciate
i-nodes], nor that the operating system says it has finished copying and
unmount the device seems impossible/ give a long waiting time, and the
hardware blinker on this usb stick I have isn't "lying". That was enough
annoyance to drop the whole ext<n> thing for me.
Now that I've came to the conclusion that jfs somehow didn't want to be
fsck'd at all, I again went with xfs for usb [only this time I attempt
to learn about what I can do and do not. Because instead of backing up,
restoring is just as important as the backup itself.
Now I've learnt that xfs has to be treated well, I saw the following
output with the command "mkfs.xfs /dev/sd<n>"
---
meta-data=/dev/sdc isize=256 agcount=4, agsize=244928
blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0
data = bsize=4096 blocks=979712, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
---
I am not only curious but also interested, what xfs is trying to tell
me, when I just asked it to create a new xfs. Since I couldn't get jfs
to do a simple 'fsck -n', and fat and ntfs are of no importance to me,
and that btrfs simply isn't meant that way and on top of that, that ext2
is a bit dated, ext3 isn't clear to me, and ext4 doesn't seem to add
much [I find], the only conclusion that I have now, is to stick with
xfs, and most of the internet advices otherwise.
I wonder if someone on this list can tell me more on the meta-data of
xfs, not my bias to xfs while I wasn't able to give jfs a proper chance.
It is kind of important for a usb backup to know what could go wrong
before anything goes wrong with the data trusted to it. That is why I am
asking here, in the hope that a knowledgeable/ experienced person could
shed some light on this. [for my main purpose, having a "pre-prepared"
disaster recovery plan, instead of just backups].
reply other threads:[~2017-07-19 22:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1500510327.1939.36.camel@versatel.nl \
--to=richardwbb@versatel.nl \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox