| To: | Steve Lord <lord@xxxxxxx>, Thomas Graichen <graichen@xxxxxxxxxxxxx>, thomas.graichen@xxxxxxxxxxxxx |
|---|---|
| Subject: | Re: short xfs_db intro ? |
| From: | "William L. Jones" <jones@xxxxxxxxxxxxxxxxxx> |
| Date: | Thu, 17 Aug 2000 15:37:08 -0500 |
| Cc: | linux-xfs@xxxxxxxxxxx |
| In-reply-to: | <200008172016.PAA08873@jen.americas.sgi.com> |
| References: | <Message from Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de> <news2mail-8ngmjr$ikg$6@mate.bln.innominate.de> |
| Sender: | owner-linux-xfs@xxxxxxxxxxx |
In general I don't think even the most sophisticated sys admin will ever have to use this command unless they were trying debug the xfs file system. xfs_db can be usefully but to a very small number of people. I like to see some work done on xfs_reapair. Just having an example that talks about how it handles lost+found would be usefully. It very confusing the first time you see it relink file the were original in lost+found. I thought it was a bug the first time I saw what it did. Bill Jones At 03:16 PM 8/17/00 -0500, Steve Lord wrote: The first trick is finding people familiar with xfs_db! I personally only use it as a tool of last resort. The only documentation I am aware of for xfs_db is the man page, it does contain information on the different metadata objects in XFS. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: short xfs_db intro ?, Steve Lord |
|---|---|
| Next by Date: | REASSIGN 799238 - RAM disk driver breaks locking hierarchy, dxm@xxxxxxxxxxxx |
| Previous by Thread: | Re: short xfs_db intro ?, Steve Lord |
| Next by Thread: | UPDATE 799238 - RAM disk driver breaks locking hierarchy, lord@xxxxxxx |
| Indexes: | [Date] [Thread] [Top] [All Lists] |